site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com - Jordan On Jun 25, 2006, at 1:32 PM, Boyd Waters wrote: On Jun 25, 2006, at 11:50 AM, Dan Shoop wrote: - boyd Boyd Waters National Radio Astronomy Observatory Socorro, New Mexico _______________________________________________ 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/jkh%40apple.com _______________________________________________ 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 think there's been a lot of confusion here about what constitutes "file metadata". First off, the ownership/mode/{creation,access} time and other inode specific data is POSIX-layer stuff and there already exist [l]stat(2) interfaces for getting this information, so sticking it in the EA list would be double-entry bookkeeping at best and confusing at worst. Second, you can hardly include "3rd party housekeeping" info like Finder's .DS_Store data in the same category since that's just some other application's view of the file, it's not data specific to the file itself. Another instance of that would be spotlight's index data for the file - would you have that associated with the file too? What about other applications? Ultimately, trying to associate all of this goop with the file itself represents a gross layering violation and something that's downright perilous to do for all sorts of application / file syncing reasons I won't go into here. What are you folks actually trying to do? Have you considered that it might be the wrong thing? :) However copyfile() doesn't seem to preserve *all* the complete, necessary and expected data associated with Mac HFS[+] files nor does the ._file mechanism. Specifically symlink ownership, creation date, and file ID info for Aliases will get clobbered. And there's also Finder information and Spotlight data stored in the .DS_Store's And currently (10.4.6) there appears to be no shipping tool that can copy a file completely. ASR, hdiutil, ditto, cp (and copyfile () reliant mechanisms) all miss something. Sometimes rather badly. It would be nice if Apple would at least stuff the creation date in the ._file under OS X. :( Wow. Which is why this review of backup software found that only *one* of all the tools available will preserve all metadata: http://blog.plasticsfuture.org/2006/04/23/mac-backup-software-harmful/ Is there really no way to copy a file - along with *all* metadata* - in one operation? This email sent to jkh@apple.com This email sent to site_archiver@lists.apple.com