Re: ANN: Backup Bouncer -- a metadata test suite
Re: ANN: Backup Bouncer -- a metadata test suite
- Subject: Re: ANN: Backup Bouncer -- a metadata test suite
- From: Nathaniel Gray <email@hidden>
- Date: Thu, 3 May 2007 15:16:58 -0700
On May 3, 2007, at 9:43 AM, email@hidden wrote:
I like your BB and used it to verify the esbdump/esbrestore
commands included in ES-Backup...
Thanks!
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.
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden