Re: Metadata support
Re: Metadata support
- Subject: Re: Metadata support
- From: "Jordan K. Hubbard" <email@hidden>
- Date: Tue, 27 Jun 2006 00:10:55 -0700
On Jun 26, 2006, at 6:45 PM, maurits wrote:
while I wouldn't wrap it in such a strong wording, I still pretty
much agree with Don's pleading for the preservation of file
creation dates upon file copying. Because it fits in really well
with my earlier blog posts on similar topics, I've turned my own
reply to Jordan into a blog post, please see
http://blog.plasticsfuture.org/2006/06/27/mac-os-file-creation-dates/
Jordan, please don't take the somewhat sensationalist title too
serious ;-) It's all meant as a constructive contribution to the
discussion, and I have no interest in building dividing walls
between people where there are none; but I guess is still
interesting to see how where people come from often influences
their reasoning - same applies to me, being an old-time Mac OS user.
Now let's hope we have some convincing arguments... :)
Let me be clear that my perspective (and arguments up until now) have
reflected my background as a UNIX guy and, in my own defense, someone
who is also employed by Apple in the "UNIX Technology Group", so if
that has lead to a perceived bias towards the POSIX API layer and the
semantics thereof, I can only say "guilty as charged." I'm also not
a traditional Mac user by any stretch, it being fairly well-known
that I didn't even use Macs until MacOSX (and my beloved UNIX) came
into the picture, nor do I typically use the Finder or other
"traditional Mac tools" when the command line can be used instead, so
think of me as part of the latest wave of UNIX greybeards who have
come to (and embraced) MacOSX if it helps you put my remarks into
context.
All that said, I'm not above learning new things or understanding the
value of old things I was previously unacquainted with, just as I do
not assume that all historical behavior is axiomatically correct
(though things are often the way they are for good reason). I did
carefully read your blog entry, as well as some of the references
(http://toadstool.se/journal/2006/01/11/the-fallacy-of-ctime is
indeed an excellent summary of the role of st_ctimespec) and, having
done so, I certainly understand what you're driving at here and why
you want it. I think this discussion has mostly gotten itself hung
up on the semantics of the "internal creation time" that HFS
currently uses vs the "birth time" extension to UFS that you mention
in your blog vs whatever the hell it is that the Finder does to clone
creation time values (and I honestly do not know what that is).
Add to this the question of Finder aliases vs symlinks and some of
the differences in MacOSX symlink behavior vs that of other UNIXen
(you'll find, for example, that lchown() only very recently made it
into the system whereas lchmod() is still unavailable). This limits
some of what we can do in restoring file metadata, and tools like tar
(1) and cp(1) truly do the best they can with the POSIX data that's
available, there also being certain guidelines we need to obey in the
UNIX command-line tool space, two of them being:
A) We can't break UNIX03 compatibility for those tools (Not an
option: That's simply the spec things have to conform to on the UNIX
side of the house).
B) We can't introduce gross layering violations, like consuming
Carbon interfaces from a UNIX tool.
That does not, however, leave us entirely without choices. For one,
the POSIX Extended Attribute data we've already touched on in some
detail is fairly open-ended and can be applied to files that live on
non-EA supporting filesystems as well as HFS (due to the unmitigated
glory that is the AppleDouble file), so one assumes that various bits
of extra information could be stored in EAs where it would be backed
up by tar(1), copied with cp(1) or synchronized with rsync(1). We
can leave the discussion as to whether those particular tools are as
wonderful as they could be for another time, suffice it to say that
they preserve EA fidelity and that's enough for our purposes.
Another option is to create NEW tools that don't need to heed those
restrictions, but it would be useful to know what the desired
semantics of such tools would be and have a clear sense of how to
design them with enough "legs" to last awhile before running off and
creating another mousetrap. The dump(8) and restore(8) tools were
mentioned at one point, for example, but most people don't realize
how filesystem-specific those tools are. They have innate knowledge
of the filesystem format and hence don't work on anything other than
UFS, so coming up with anything similarly tied to HFS wouldn't be a
very future-proof decision, even if it did preserve things like HFS
Finder info (which apparently lives in the HFS catalog itself).
In either scenario, we're still faced with trying to figure out how
to meld two worlds together. If there's a magic EA which denotes
file "birth time" (to borrow Kirk's terminology), for example, where
and how should it be used? Can anyone set it? What about when a new
file is created on a filesystem which doesn't support EAs, meaning
you can't rely on a helpful HFS to say "Oh, I've just created this,
I'll go write that magic birth time EA value for you." Who's now
responsible for writing this out? The creat(2) and open(2) calls?
How much extra filesystem I/O would that generate when, say,
extracting large archives of files? Perhaps the cost would be deemed
worth it for "birth time", but one can also probably safely assume
that things wouldn't end there.
I'm also always generally leery of creating mechanisms which parallel
existing ones given that someone, somewhere, will eventually expect
them to play nicely together. It's the idea of making all the UNIX
tools play nicely with this brave new world ("ls(1) should display
the new birth time! ln(1) should support finder aliases!") that
keeps me up at night, and if you think people won't ask, you should
see how many requests we got to make passwd(1) talk properly to
Directory Services (even though there was a "perfectly usable"
password setting function in the accounts pane of System Preferences)
until we finally went and did it.
Does that mean that I'm disagreeing with the notion that this is
worthwhile nonetheless, even given the extra work involved? No, I'm
not disagreeing with that notion, I'm simply saying that it
represents Actual Work, and that has a way of being prioritized in
many different ways given the non-zero cost of engineering. I'd be
happy to continue the discussion offline; I'm sure most people on the
list have somewhat gone off the topic by now...
- Jordan
_______________________________________________
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