site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On May 3, 2007, at 9:43 AM, mlists@ugsoft.de wrote: Thanks! Cheers, -n8 --

...

...

-- Nathaniel Gray -- Caltech Computer Science ------> -- Mojave Project -- http://mojave.cs.caltech.edu -->

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I like your BB and used it to verify the esbdump/esbrestore commands included in ES-Backup... Some notes, IMHO: - I doubt it is sensefull testing the "busy" Finder flag on directories to be backed up and failing this test if not. Even if a directory is busy on the source, this flag should not be copied over to the destination, since this is something the Finder should set/unset. I imagine that's probably reasonable, though I can only guess what the busy flag means. I'm gradually learning the semantics of those flags and understanding which should be tested for preservation. - Another issue is the Finder "lock" flag and the "uchg" BSD flag on files and directories: Setting them in the destination might result in not being able to modify this file/directory during the next (incremental) restore, rsync, copy, etc. When carrying out a UNIX cp this seems to be an expected behaviour, but e.g. when doing synchronizations or incremental restores, it depends on what the user expects as the result on the destination, e.g.: A source directory was locked and synced to the destination. Before the next sync takes place I unlock the source directory and copy files to it and afterwards lock it again. Should I expect to have the new files in the locked destination directory after the next sync was carried out? So not copying the "lock" flag might or might not be a reason to fail this test. BB is primarily intended to test the archival capabilities of a tool. If I set the "lock" bit on a file, archive my system, and later restore it, then I want the lock bit to still be set. I may be using the flag to protect my valuable files from accidental deletion, and that configuration is part of what I'm trying to archive. I think that the question of whether or not to respect the lock flag during incremental updates is a policy issue that the user should have control over, not one that the tool should impose on him. If I'm using rsync to keep a "mirror image" of my system, then I want to override it during incremental backups. OTOH, there may be reasons not to. But if the tool won't copy the lock flag at all then yes, I think it should fail the test. This email sent to site_archiver@lists.apple.com