On Mar 9, 2011, at 8:42 PM, Dan Shoop wrote: > > On Mar 9, 2011, at 10:38 PM, Chris Murphy wrote: > >> We'd have serious problems if that were not the case. > > We do. As I've pointed out Finder can't even see whole sets of files.
The context is data files. I'd be curious what "whole sets" of data files the Finder does not see, does not copy when asked, and does not inform the user. That would be a rather considerable kind of data loss on copy for a "do no evil, do not harm" system. > >>>> And an even larger sample size exists if filesystems other than jhfs+ are >>>> considered. RAID 5/6 are common with ext3, ext4, XFS and other file >>>> systems without anyone suggesting RAID 5 in particular is known for itself >>>> increasing the incidence of silent data corruption. >>> >>> Sorry to be blunt: What rock have you been under? >> >> You are conflating a higher incidence of silent data corruption with a known >> deficiency with RAID 5/6. They are not the same thing. Feel free to repeat >> yourself, though. > > No let me repeat: silent data corruption only occurs under raid5 Hahahahaha! OK. Great. AT least you wrote it out finally. You are confused. > >>>> CCC is not rocket science. I have a new version, it does not produce >>>> identical copies of all files in all cases. >>> >>> Since Backup Bouncer demonstrates it does, to what are you referring? >> >> hfsdebug indicates the original and cloned/copied files are not the same. >> With Time Machine restores, they are. >>> > > Since I must not be following you since I don't see this empirically please > provide and example. The full hfsdebug listing is too long for two small files to past into email. It is easy to reproduce. hfsdebug the original, assuming it was originally installed by OS X's installer in the first place, or restored by Time Machine, and not from a bogus restore process. And then use your choice of copy: Finder, cp, Disk Utility, asr, rync, or CCC. And then hfsdebug that cloned version. Not the same. Obviously not the same. The two files *function* the same. They do not take up the same amount of space on disk, and HOW their data is stored are not *identical* which was the first thing I said. Not identical. > > >>>> While the cloned system was perfectly functional, at a file system level >>>> they were not *identical* to the original, which is a very specific >>>> meaning. >>> >>> Again, in what way? >> >> Data stored in attributes was restored into the data fork. Storage >> requirement for files doubled to quadrupled. That is not identical to the >> original. > > Then you used the tool differently. I use it in the simplest and most obvious possible manner, closest to defaults. I tend not to change defaults unless I have a very explicit reason why. So fine - maybe there is some setting that needs to be set to get identical clones. The default of Time Machine backups and restores does this already. With CCC, Finder, cp, asr, Disk Utility, this is not the default result, and it's not obvious how one would alter the behavior to get an identical result. Should one care. > >>>> Disk Utility is using asr. It does *not* restore or copy files identically >>>> to the original. >>> >>> No, disk utility and asr are quite different but perform a similar >>> operation using different code and operations. Watch a sc_usage or dtrace >>> of each and you'll see they're operating quite differently. >> >> I have watched Disk Utility while doing disk to disk copies and the only >> process it spawned was asr. Only asr was producing file system usage to the >> target drive. > > This is not accurate across all OS X versions of the tool. I have tested this with the 10.6.4 through 10.6.6 versions of Disk Utility disk to disk copy. The results are non-identical, but apparently fully functional, copies. Chris Murphy_______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
