Re: Metadata support
Re: Metadata support
- Subject: Re: Metadata support
- From: Dan Shoop <email@hidden>
- Date: Sun, 25 Jun 2006 22:29:54 -0400
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?
I thought I answered that as unnecessary since it would just be re-created.
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.)
Is asking for either of those a "wrong thing"?
--
-dhan
------------------------------------------------------------------------
Dan Shoop AIM: iWiring
Systems & Networks Architect http://www.ustsvs.com/
email@hidden 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden