![]() I agree with your observation that ditto probably can't preserve links "across copy operations".įor fun, I checked to see how many hard links are in my OS X installations. Thanks for your reassurance that unrolling hard links has not caused any trouble. I'd love to see a FileMerge source/target listing comparison that shows only expected differences, rather than hundreds of disquieting extraneous ones caused by quirks of the cloning method. Thanks for looking into the hard links issue. The symbolic link updating phenomenon with asr and CCC is a real nuisance, because it causes huge numbers of uninteresting differences. That's how I discovered the loss of hard links with SuperDuper, and confirmed their complete preservation with asr and CCC. Incidentally, to fully explore the results of a cloning operation, I generate complete volume listings (sudo ls -lonTRA > ~/desktop/list.txt) of source and target, and compare them with FileMerge. (I don't understand why in either case.) Note that asr and CCC/ditto took almost exactly the same amount of time to complete the clone, suggesting they're using the same copying method. ![]() My evidence is that modification dates of all symbolic link files (on the target) were updated during asr's operation. In this simple application (source not an image), it apparently does not do a low-level block copy. Sudo asr -source / -target /Volumes/ -erase -verbose (Apparently that condition holds in Mac OS X's hard links, because I found no reduction in link counts within the CCC generated clone.) I would imagine that as long as all hard links to a particular inode are within one of the copied folders (like usr), ditto wouldn't need to unroll any of them. Sudo /usr/bin/ditto -rsrcFork /'usr' '/Volumes/'/'usr' Sudo /usr/bin/ditto -rsrcFork /'Applications' '/Volumes/'/'Applications' According to CCC's log, it uses a series of ditto commands like this: ![]() I simply used Carbon Copy Cloner, and observed that hard links were preserved. Sorry for the confusion.Īlso, I did not test ditto directly. In my tests, I cloned the entire boot volume, then checked /usr/share/zoneinfo/US on the target to quickly see what happened to link counts. The hard linked files in that directory aren't hard linked to each other, so copying that directory by itself doesn't seem very revealing. I should have been more clear about how I used /usr/share/zoneinfo/US for testing. I hope your time at WWDC was useful and enjoyable! Anyone more savvy about these things have any thoughts? I'm new to SuperDuper, and I'm no expert on unix either, but this seems like an issue worth exploring. They both play it safe and preserve hard links. (A simple test directory is /usr/share/zoneinfo/US.)įor comparison I tried cloning using the asr command in Terminal, and also Carbon Copy Cloner (which uses the ditto command). Hard links are especially abundant in /usr/share/. Do we know that all those hard linked files are never manipulated by Mac OS X, so there's no need to worry? Couldn't third party software use hard links and get tripped up by this too? This seems like a waste of space, but more importantly, could lead to software malfunctions if hard links are assumed to exist when files are updated. That means that the original file, which had multiple directory entries pointing to it, has been duplicated so that each directory entry points to its own copy. Instead of multiple directory entries sharing a single inode number, each directory entry ends up with a unique inode number. Source files (not directories) with a link count higher than 1 inevitably show up on the target with a link count of 1.Įxamining inode numbers adds more evidence that hard links are lost. This can be observed in Terminal by using the "ls -li" command. After doing a simple clone operation to create a bootable volume, I see that hard links are apparently not preserved. One discovery has me a bit puzzled and concerned. I'm a new owner of SuperDuper, and I've been doing some testing under Mac OS X 10.3.9.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |