May 2007 - Darwin-dev - lists.apple.com

Re: ANN: Backup Bouncer -- a metadata test suite
by Nathaniel Gray 03 May '07

03 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 3, 2007, at 9:43 AM, mlists(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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(a)lists.apple.com

1 0

Re: ANN: Backup Bouncer -- a metadata test suite
by mlists＠ugsoft.de 03 May '07

03 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Uwe Hi folks, ------------------ rsync-apple ------------------ This copier exited with error code 24 This copier produced log output in: /Volumes/Dst/10-rsync-apple/log Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok Verifying: resource-forks ... FAIL Verifying: finder-flags ... FAIL Verifying: finder-locks ... FAIL Verifying: creation-date ... FAIL Verifying: bsd-flags ... FAIL Verifying: extended-attrs ... Sub-test: on files ... FAIL Sub-test: on directories ... FAIL Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... FAIL Sub-test: on dirs ... FAIL FAIL Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... FAIL Sub-test: lots of metadata ... FAIL FAIL And here are the results from tar: ------------------ tar ------------------ This copier produced log output in: /Volumes/Dst/50-tar/log Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok Verifying: resource-forks ... FAIL Verifying: finder-flags ... FAIL Verifying: finder-locks ... FAIL Verifying: creation-date ... FAIL Verifying: bsd-flags ... FAIL Verifying: extended-attrs ... Sub-test: on files ... FAIL Sub-test: on directories ... FAIL Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... FAIL Sub-test: on dirs ... FAIL FAIL Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... FAIL Sub-test: lots of metadata ... FAIL FAIL On a happier note, here are the results from cp -Rp: ------------------ cp-apple ------------------ Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... FAIL Verifying: hardlinks ... FAIL Verifying: resource-forks ... ok Verifying: finder-flags ... ok Verifying: finder-locks ... ok Verifying: creation-date ... FAIL Verifying: bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... ok Sub-test: on directories ... ok Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... ok Sub-test: on dirs ... ok ok Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... ok ok Find out more here: http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/ 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/mlists%40ugsoft.de _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. - 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. At 18:30 Uhr -0700 01.05.2007, Nathaniel Gray wrote: I'm pleased to announce the first release of Backup Bouncer, a tool to keep the ugly backup tools out of the club. To be more precise, BB is a tool for systematically testing backup tools in OS X, with a focus on ensuring proper preservation of file-related metadata. It contains a suite of tests to verify that metadata has survived a copy operation, along with a suite of copiers. It will even automatically prepare disk images as source/destination targets for you. How is this relevant to darwin-dev? Well, the results of the various copy/archival tools in Tiger leave much to be desired. Here are the results from rsync: Anyhow, I know you're aware of many of these problems. I hope that having an automated test suite can help you to find and solve them. -- This email sent to mlists(a)ugsoft.de This email sent to site_archiver(a)lists.apple.com

1 0

Re: ANN: Backup Bouncer -- a metadata test suite
by Nathaniel Gray 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 2, 2007, at 4:17 PM, Axel Luttgens wrote: On 3/05/07 0:52, Nathaniel Gray wrote: [...] 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Until they didn't. On the evening of April 24 Don't remember exactly, but hasn't security update 2007-004v1.0 been released around that date? Could you check if you have installed it, and when? That's not the issue. I didn't install that update until later. I remember because I installed it just before I transferred everything to my new hard drive with dd_rescue. Really, I didn't do anything except hack on BB between the time that rsync worked and the time that it failed. No updates, no reboots. I was (and still am) utterly baffled. Because it seems it came with an enoooorrmous regression... Could you have a look at AFP548's article about rsync, describing the behavior of rsync up to 10.4.9 (without the subsequent security updates) and see if it more or less accurately describes your previous, working, environment? Maybe. I saved a result from a test just before the "transition" occurred: ------------------ rsync-apple ------------------ Verifying: basic-permissions ... ok Verifying: symlinks ... ok Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok Verifying: resource-forks ... ok Verifying: finder-flags ... ok Verifying: finder-locks ... FAIL Verifying: creation-date ... ok Verifying: bsd-flags ... FAIL Verifying: extended-attrs ... FAIL Verifying: access-control-lists ... ok Verifying: fifo ... ok Verifying: devices ... ok The ACL test was broken in this revision, as was the creation date test. This was a copy from a source volume with ACLs disabled. This email sent to site_archiver(a)lists.apple.com

1 0

Re: ANN: Backup Bouncer -- a metadata test suite
by Axel Luttgens 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 On 3/05/07 0:52, Nathaniel Gray wrote: [...] Axel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Until they didn't. On the evening of April 24 Don't remember exactly, but hasn't security update 2007-004v1.0 been released around that date? Could you check if you have installed it, and when? Because it seems it came with an enoooorrmous regression... Could you have a look at AFP548's article about rsync, describing the behavior of rsync up to 10.4.9 (without the subsequent security updates) and see if it more or less accurately describes your previous, working, environment? This email sent to site_archiver(a)lists.apple.com

1 0

Re: ANN: Backup Bouncer -- a metadata test suite
by Axel Luttgens 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 On 2/05/07 12:03, I wrote: [...] After all, could well be the case. I thus re-phrase: have you installed the 2007-004 update? Axel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Did you get your own results on a clean 10.4.9 install? This email sent to site_archiver(a)lists.apple.com

1 0

Re: ANN: Backup Bouncer -- a metadata test suite
by Nathaniel Gray 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com cd ~/Desktop/backup-bouncer-0.1.1 make ./bbouncer create-vol Src ./bbouncer create /Volumes/Src ./bbouncer create-vol Dst ./bbouncer copy -d -c 10-rsync-apple /Volumes/Src /Volumes/Dst Thes are the results I get here: ------------------ rsync-apple ------------------ Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok Verifying: resource-forks ... ok Verifying: finder-flags ... ok Verifying: finder-locks ... FAIL Verifying: creation-date ... FAIL Verifying: bsd-flags ... FAIL Verifying: extended-attrs ... Sub-test: on files ... ok Sub-test: on directories ... ok Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... ok Sub-test: on dirs ... ok ok Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... ok ok Cheers, -n8 P.S. Please CC me with replies -- I don't get mail from the list. -- >>>-- 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Axel Luttgens wrote: After having extracted the archive on the Desktop, I just ran those commands: without having changed anything in your code (of course, I first checked it wasn't some kind of bad April joke ;-) ). on an Intel box as well as a PPC one. Ah! Interesting! I was hoping to find someone like you. This means I have to tell a story. I didn't develop BB entirely for fun. The drive in my PBG4 started developing bad blocks and I needed to replace it. ASR fails on I/O errors, so I started thinking about file-by-file archival tools. (However, in the end I used dd_rescue -- I recommend it highly.) The plasticsfuture blog post from a year ago[1] left me full of doubt about most tools, so I decided the only way to be sure of what would happen would be to do my own testing. As I developed BB I found that the results were not so bad. My results looked like what you see above, and I got the same results for tar. So I decided to go ahead and use rsync as my backup tool, thinking it had been fixed. I booted from the Tiger install DVD, mounted both my drives, and started my copy, being sure to use the path to the up-to-date rsync on my system drive. The result? My copy was a disaster. No finder flags, no resource forks. I tried again with tar and got the same result. I tried using DYLD_LIBRARY_PATH to make sure dynamic libraries were loaded from the system drive as well, but still no luck. And all the while, my unit tests were telling me it should all just work. Until they didn't. On the evening of April 24 (according to the svn logs) I was doing my best to trigger the failures I'd seen when actually backing up. I tried disabling ACLs on my BB source volume (to mimic my root volume), but nothing happened so I re-enabled them. I did some minor tweaking of my code, including adding a test for ACLs on directories and symlinks, but nothing that should have had a big impact. Suddenly, the tests started failing for me, and I couldn't find any way to get them to succeed again. I tried reverting the code and starting with fresh disk images, but no matter what I did, I got the failures. I would have thought this was a *bad* thing, but my results now matched the plasticsfuture results, and fresh checkouts on two colleagues' intel macs gave the same results. So I have no idea why rsync/tar work on some systems and not on others. One potential hint has to do with ACLs. BB tests copying from a volume with ACLs enabled to another volume where they're enabled. However, as I mentioned, I realized that they're *not* enabled on my root volume, so I tried disabling them on my BB source volume. Nothing happened -- the tests still passed. However, it was soon thereafter that they failed (within an hour or so). Did you get your own results on a clean 10.4.9 install? No, not at all. I'm using my hard-working laptop. I don't have access to a clean 10.4.9 install. However, my results seem to be replicable on a variety of 10.4.9 systems. [1] - http://blog.plasticsfuture.org/2006/03/05/the-state-of-backup- and-cloning-tools-under-mac-os-x/ This email sent to site_archiver(a)lists.apple.com

1 0

Re: ANN: Backup Bouncer -- a metadata test suite
by Axel Luttgens 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 On 2/05/07 3:30, Nathaniel Gray wrote: Hi folks, [...] ------------------ rsync-apple ------------------ This copier exited with error code 24 This copier produced log output in: /Volumes/Dst/10-rsync-apple/log Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok Verifying: resource-forks ... FAIL Verifying: finder-flags ... FAIL Verifying: finder-locks ... FAIL Verifying: creation-date ... FAIL Verifying: bsd-flags ... FAIL Verifying: extended-attrs ... Sub-test: on files ... FAIL Sub-test: on directories ... FAIL Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... FAIL Sub-test: on dirs ... FAIL FAIL Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... FAIL Sub-test: lots of metadata ... FAIL FAIL cd ~/Desktop/backup-bouncer-0.1.1 make ./bbouncer create-vol Src ./bbouncer create /Volumes/Src ./bbouncer create-vol Dst ./bbouncer copy -d -c 10-rsync-apple /Volumes/Src /Volumes/Dst Thes are the results I get here: ------------------ rsync-apple ------------------ Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok Verifying: resource-forks ... ok Verifying: finder-flags ... ok Verifying: finder-locks ... FAIL Verifying: creation-date ... FAIL Verifying: bsd-flags ... FAIL Verifying: extended-attrs ... Sub-test: on files ... ok Sub-test: on directories ... ok Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... ok Sub-test: on dirs ... ok ok Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... ok ok on an Intel box as well as a PPC one. Did you get your own results on a clean 10.4.9 install? Curiously, Axel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… How is this relevant to darwin-dev? Well, the results of the various copy/archival tools in Tiger leave much to be desired. Here are the results from rsync: After having extracted the archive on the Desktop, I just ran those commands: without having changed anything in your code (of course, I first checked it wasn't some kind of bad April joke ;-) ). This email sent to site_archiver(a)lists.apple.com

1 0

Re: how to detect inserted DVD media from bash or Perl?
by Graham J Lee 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 2 May 2007, at 10:10, Graham J Lee wrote: I think my vices could do with a versa. Graham. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… it has a while(){} instead of a do{}while(), so if the path already exists, it doesn't return until an appropriate event occurs. This email sent to site_archiver(a)lists.apple.com

1 0

Re: how to detect inserted DVD media from bash or Perl?
by Graham J Lee 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 15 Apr 2007, at 19:32, Steve Hayman wrote: On 14-Apr-07, at 4:24 PM, jmzorko(a)mac.com wrote: Cheers, Graham. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… How do I detect the presence / insertion of a DVD, much like the autorun mechanism on Linux? I want to automatically run certain operations when the system detects that a DVD with certain files has been inserted. Since this is a quick weekend project for a friend, i'd like to be able to do it in Perl or bash if possible (the "certain operations" I speak of are basically decompress the files and copy them to a certain place). The DVD will likely be created on a Linux or Windows box. You might try using "wait4path /Volumes/MyDVD", which simply waits for a specified path to show up; if the path isn't found, it sleeps until the mount table is updated and then checks again. wait4path exits when the path is finally there. Interesting behaviour wait4path has though...it has a while(){} instead of a do{}while(), so if the path already exists, it doesn't return until an appropriate event occurs. Try "wait4path /" for instance. I sent a patch in to bugreporter a good while ago, so maybe 10.5 works differently... This email sent to site_archiver(a)lists.apple.com

1 0

ANN: Backup Bouncer -- a metadata test suite
by Nathaniel Gray 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi folks, ------------------ rsync-apple ------------------ This copier exited with error code 24 This copier produced log output in: /Volumes/Dst/10-rsync-apple/log Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok Verifying: resource-forks ... FAIL Verifying: finder-flags ... FAIL Verifying: finder-locks ... FAIL Verifying: creation-date ... FAIL Verifying: bsd-flags ... FAIL Verifying: extended-attrs ... Sub-test: on files ... FAIL Sub-test: on directories ... FAIL Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... FAIL Sub-test: on dirs ... FAIL FAIL Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... FAIL Sub-test: lots of metadata ... FAIL FAIL And here are the results from tar: ------------------ tar ------------------ This copier produced log output in: /Volumes/Dst/50-tar/log Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok Verifying: resource-forks ... FAIL Verifying: finder-flags ... FAIL Verifying: finder-locks ... FAIL Verifying: creation-date ... FAIL Verifying: bsd-flags ... FAIL Verifying: extended-attrs ... Sub-test: on files ... FAIL Sub-test: on directories ... FAIL Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... FAIL Sub-test: on dirs ... FAIL FAIL Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... FAIL Sub-test: lots of metadata ... FAIL FAIL On a happier note, here are the results from cp -Rp: ------------------ cp-apple ------------------ Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... FAIL Verifying: hardlinks ... FAIL Verifying: resource-forks ... ok Verifying: finder-flags ... ok Verifying: finder-locks ... ok Verifying: creation-date ... FAIL Verifying: bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... ok Sub-test: on directories ... ok Sub-test: on symlinks ... FAIL FAIL Verifying: access-control-lists ... Sub-test: on files ... ok Sub-test: on dirs ... ok ok Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... ok ok Find out more here: http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/ 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I'm pleased to announce the first release of Backup Bouncer, a tool to keep the ugly backup tools out of the club. To be more precise, BB is a tool for systematically testing backup tools in OS X, with a focus on ensuring proper preservation of file-related metadata. It contains a suite of tests to verify that metadata has survived a copy operation, along with a suite of copiers. It will even automatically prepare disk images as source/destination targets for you. How is this relevant to darwin-dev? Well, the results of the various copy/archival tools in Tiger leave much to be desired. Here are the results from rsync: Anyhow, I know you're aware of many of these problems. I hope that having an automated test suite can help you to find and solve them. This email sent to site_archiver(a)lists.apple.com

1 0