Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Metadata support
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Metadata support

On Jun 25, 2006, at 7:29 PM, Dan Shoop wrote:

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.

OK, creation date is admittedly special. Let's call it "filesystem internal" metadata for the purpose of tracking when a file was created. I mistakenly lumped it into my list of stat(2) data due to a faulty memory of the st_ctimespec field in the stat structure, but that doesn't change the facts. I believe the creation date is not something you're intended to spoof - it's when the file was created. If you create a backup file, that backup file will have its own creation date. If you restore from backup in such a way that the original file is deleted and replaced (e.g. a new inode is allocated) then, by all rights, the new file is not the same as the old file and should have its (newer) creation date reflect this. FWIW, this behavior is not unique to MacOSX.

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.

cp copies all the relevant metadata, why don't we rephrase it that way? :)

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.

This statement suggests some confusion about the purpose of the AppleDouble file.

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.

That is, indeed, how the philosophy is defined. :) If you want to backup files by copying them, you simply need to get used to the notion that this creates new files. I enjoy backing up files by copying them as much as the next guy (some people collect bottlecaps, I copy files) and this doesn't bother me at all.

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.

What about the symlinks? They're files too, of a sort (they used to have far less metadata of their own in HFS, which I considered a bug, but that's been getting better over time), and you can't tweak their creation time either, so I can't see why they change the discussion unless I, too, am missing something.

But the Finder Comments (which is what Spotlight Comments seem descended from) were considers so before in classical Mac OSen, no?

I can't speak for the classical Mac OSen, but I can say that MacOSX is descended from UNIX and hence is a child of different parents, so to speak, and the fundamentals are going to reflect that.

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.

It was simply an example. One could contrive any number of per- application scenarios where an application wanted to track information about a file in a side-database and wouldn't necessarily re-create that database on demand. Does that mean that backup programs should suddenly become aware of such applications? My doubts about this were the only point I was trying to convey with the spotlight scenario.

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.)

I would argue that tar already does a pretty good job of this. You and I may disagree about the creation date semantics, but tar will back up your files, and their POSIX metadata, and the EA metadata (along with the ACLs), and even those pesky .DS_Store files if you're backing up the whole volume (or, at least, whole directory trees), so no, that's not an unreasonable thing to ask for and yes, we provided it. We even gave you rsync -E, for those cross-machine scenarios.

I haven't seen anything in this discussion to suggest that those mechanisms are inadequate for restoring data in a useful form, simply some argument about the importance of creation time.

- 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

 >Metadata support (From: Tomas Zahradnicky <email@hidden>)
 >Re: Metadata support (From: Q <email@hidden>)
 >Re: Metadata support (From: Dan Shoop <email@hidden>)
 >Re: Metadata support (From: Boyd Waters <email@hidden>)
 >Re: Metadata support (From: "Jordan K. Hubbard" <email@hidden>)
 >Re: Metadata support (From: Dan Shoop <email@hidden>)

Visit the Apple Store online or at retail locations.

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.