site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com I thought I answered that as unnecessary since it would just be re-created. Is asking for either of those a "wrong thing"? -- -dhan ------------------------------------------------------------------------ Dan Shoop AIM: iWiring Systems & Networks Architect http://www.ustsvs.com/ shoop@iwiring.net http://www.iwiring.net/ 1-714-363-1174 pgp key fingerprint: FAC0 9434 B5A5 24A8 D0AF 12B1 7840 3BE7 3736 DE0B iWiring provides systems and networks support for Mac OS X, unix, and Open Source application technologies at affordable rates. _______________________________________________ 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... At 6:02 PM -0700 6/25/06, Jordan K. Hubbard wrote: I think there's been a lot of confusion here about what constitutes "file metadata". Can we be clear that "creation date" is metadata? It's not file data, but it's important to both the filesystem (or should be), the user and applications that make use of them. It walks like a duck. First off, the ownership/mode/{creation,access} time and other inode specific data is POSIX-layer stuff and there already exist Except that things like creation date aren't POSIX metadata. POSIX tools, unless made aware of these through the likes of copyfile(), aren't going to deal with creation dates. Hence cp, when copying a file, fails to maintain this metadatum from the source to the target. Foreign file systems aren't going to store them either. Which is why Apple Double is supposed to store this in ._file. But it appears that OS X doesn't. [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. Hence if we wish to maintain creation dates, which Mac users are used to having, that we deal with the need to stick it someplace, and this, IIRC, was defined as the Now you could define the philosophy that if you're copying a file you're creating a new copy so that new copy should have it's own creation date, but this flies against being able to backup a file by copying it. And then there's the ownership you bring up. What about it and symlinks? This doesn't appear to suffer from any similar philosophic quandary. Perhaps I'm missing it. 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. But the Finder Comments (which is what Spotlight Comments seem descended from) were considers so before in classical Mac OSen, no? 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? What "applications"? We're talking what is and isn't part of a file, stuff that exists agnostic to any application. Stuff like creation date, "Label", flags that apply to the file. 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. Well there's some things that are "goop" and some things that the filesystem or POSIX or history has already answered as being intimately associated with the file, like owner, creation date, Finder Comments. What are you folks actually trying to do? Have you considered that it might be the wrong thing? :) Copy a file. Make a new target file given an existing source file. Maintian all it's data and appropriate metadata so that to it's users it appears the same. If, as a user, I rely on something as simple as knowing when I created some file, say a photo I took, so that I can sort them, that this information is mangled when I copy it is annoying and unexpected. Likewise there should be SOME tool that can clone files or at least volumes at a logical level (other than a physical level like dd.) This email sent to site_archiver@lists.apple.com