On 24 March 2012 04:34, Graham Cobb <[email protected]> wrote: > My earlier assumption that this problem was caused by the bug fixed upstream > in dar 2.4 is incorrect. I have now installed dar 2.4.2.1 (Wheezy) and this > bug is still occuring. In fact it is now much worse because it does not just > affect archives created with old versions of dar but prevents all differential > backups being taken, breaking my whole backup strategy. I will have to > downgrade to an earlier version of dar.
Upstream had the following response. Is there any chance you can talk to upstream directly? http://sourceforge.net/tracker/?func=detail&aid=3511151&group_id=65612&atid=511612 Thanks Hello Brian, dar_manager expects that the mtime and ctime increases for a given file from archive to archive in the database. mtime is used to track modification of data, while ctime is used to track modification of inode and Extended Attributes. The provided script set back mtime of a/test to the date of yesterday in the second archive, which is not a "usual" operation. In a normal system usage, mtime, ctime and atime are modified to the date of 'now' when data modification, inode modification or read access occurs, so as system yet never traveled back to the past (as far as I know) the reported warning should not show. This "problem" shows when, the mtime or ctime is manually set to a given time in the past, either manually by using the 'touch' command, as in the provided script, or when restoring a file from dar archive or extracting it from tar, which I suspect is underlying in debian package management tools. A workaround is to use dar_manager's -ai option, which appeared in release 2.4.3 (but please directly use 2.4.4 as release 2.4.3 is broken about its ability to read dar_manager database it generates). This option does not solve any problem, it only hides the warning: Why the problem is not solved? As stated above, if the order of dates is not increasing with archive number for the mtime of a particular file, -w option of dar_manager may not work as expected for that particular file, as it may find two or more versions "just before" the date provided with -w option, and will arbitrarily restore the first one it met. If we assuming the user did not make any mistake in the order archive got provided in spite of the non increasing order of mtime dates for a particular file. A more sophisticated work with dates should be done about the lookup of file's version at a particular date [upon feature request, that could be the object of a feature in 2.5.x]. And then if the user did really made a mistake, there is no way to warn the user as we assumed the order is correct. So there is a choice to do between an expected use of dates and user error possible to detect and on the other hand, an unusal play with dates and the impossibility to report errors that could leading to restoring the wrong version of a file. I just wonder why upgrading a package in Debian leads to have some files with older mtimes? Couldn't be possible that restoring a package makes the newly created file get as mtime the current date (the date of the upgrade)? I suspect this is what would naturally do the operating system if the --preserve option of tar was not used for example. Note also, that some particular security tools also expect the mtime not to be set back in the past. Regards, Denis. -- Brian May <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
