PDF documents, as well as OpenOffice or MS Word documents, have their own internal creation and modification dates. Document Properties in Adobe Reader, Document Info in Preview, Properties in OO/Word can reveal them.

My Finder’s Get Info windows seem to honour the original creation date for .doc files, so a file downloaded via Web today may appear to be created years ago, as it should.

On the contrary pdfs downloaded today always show the creation date as Today. The worst thing is that metadata (in the More Info section of Finder’s Get Info) contains everything except the true creation date. This is only available via Preview or Adobe Reader.

In brief there are deep inconsistencies about creation/modification dates, depending on the kind of document. They should be fixed.

If you are accustomed in making searches and collecting documents on particular topics, it makes sense to be able to sort them by their true creation date, so you’ll be able to see an historical perspective of the topic development.

OS9 was surely better, even lacking a metadata framework. Internet Explorer was instructed to set the creation date of a downloaded document as the Last Modified date sent by the http server in the http header response. Frequently this was not very much different from the true creation date.

The lack of a consistent creation/modification date is a big decremental for research work.

What you need is “Picture Taken Date”, which might be available in some of the image metadata blocks. If you do that you can leave all low level operations up to Apple engineers for internal use.

We are miffed at our district.

Thanks Deric

“I appreciate that it may be a bit hard at first to agree with my arguments if one comes from a geekier background than most Mac users do; it may be weird to see that Mac users care about such subtleties (Windows users definitely wouldn’t)…”

I beg to differ. I’m both a Windows user and quite geeky, and I have lamented the crappy file creation time (and metadata in general) problem on Linux for some time, because it’s the same as on OS X (useless).

In fact, it may be worse, because the behavior of many common programs (including Emacs, probably my fourth-most-used program behind Firefox, Thunderbird, and the shell, and also Vim) when you save essentially creates a new file as far as the file system is concerned. This means that “creation dates make their way into systems such as FreeBSD” is really missing an important point, which is that even inode birth time is a crappy file creation time.

Anyway, the whole metadata thing with file systems is complete crap, because they have all these nice features which could be used for some really awesome stuff, but you can’t actually use for a lot of it because the data is too easily lost.

I also have some replies to the comments here. I have a habit of sensationalizing arguments to show what I see are flaws, so here goes:

John Fieber (#6): “I don’t think creation date can be sensibly defined in a context independent fashion.”

I personally think a reasonable attempt that doesn’t capture all cases but captures many is way better than not doing anything at all. If I were to sensationalize your argument, I would say you want to be useless in all cases instead of useless in just some.

Teva Merlin’s response (#8) is, I think, quite reasonable.

Peter da Silva (#14): “The creation date should be taken from the file’s internal metadata, unless you have reason to suspect that the clock in your camera is incorrect.”

Why? What if you’re using a format that doesn’t have a place for it? If I were to sensationalize your argument, it would be “let’s use a bunch of ad-hoc ways of storing the file creation time (EXIF in images, a comment at the top of a source file, a last revision date at the bottom of a Word document) instead of one uniform, easily-retrievable location.”

Jamie Lokier (#28): “But many applications don’t preserve the creation time when you save the file over the original.”

I would strongly argue that such programs are broken.

There are plenty of ways around this; the simplest is to copy old->new instead of move, truncate the old, then write to the old. (The old is the file the user is editing, and new is the backup file, e.g. blah~.) This doesn’t work as well for large files (unless you have a COW file system, which would also be very nice), but for a lot of things is okay.

If we actually want to think about how we can improve things instead of work around the limitations of what Ken Thompson thought a file system should be like back in 1970, we can look at Vista’s transactional NTFS, which solves the crashing problem without causing metadata loss or annoying ~ files sitting around.

I have noted that the process used to install MacOS system software somehow manage to use dates PRIOR to the date of the software installation for files and folders, which blows any argument for using the filesystem’s local creation date/time as the creation date away. It was obviolusly important for system software – Users’ files should be afforded the same function.

Daniel O’Leary Long-time Unix (and Macintosh) user.

Perhaps we should realize that we are indeed comparing apples to oranges…..

For a system it is indeed plausible that there be a “creation date” which reflects the date and time that the act of adding the file to the file structure took place.

This is different than, to coin a term, the “inception date” which determines the first date that the file’s contents came into being or, to put it another way, became useful in some manner.

For example, for a digital voice recorder of the type used to document meetings, we might set an “inception date” which, for the physical recorder, could be the same as creation date. Upon copying that file to a hard drive for further manipulation we might end up with a file creation date for the day and time it was copied, whereas the “inception date” remains the one originally supplied by the recorder.

Perhaps it should depend truly on whether a file is being copied from a domain outside of the original (i.e. from a recorder to the computer) or whether the contents are acutally being authored and stored within the same domain (recorded and saved on a recorder && recorded and saved on an actual computer)

It is my thought that there really needs to be some attention paid to interoperability standards when it comes to copying, moving, or otherwise performing some “location” related activities with a file.

Of course, one should need to be able to set the “inception date” to mark the starting period of the files “data” validity.

Certainly contact LaCie.

Do you happen to be in a timezone 1 hour from GMT? Reason I ask is I seem to recall that HFS (and most unices, and maybe NTFS) all keep the date stamps for files in GMT. (The times in the “ls” listing are adjusted based on your tz timezone setting). But some FAT filesystems keep date stamps for files in local time. See what the timezone setting of your lacie nas looks like?

And, this means, to Aunt Tillie, if she does a file “Get Info” and tells that pdf to “Open with” Preview instead of Adobe, the “Date Modified” changes in the Finder, even though the pdf file contents (data fork) is unchanged. You can’t undo the change of “Open with” to get back the original date, either. (Oddly enough, changing the status to locked (or unlocked) does NOT change the “Date Modified”. )

I think there are lots of Aunt Tillies who expect:

(A.) the creation date should be preserved when copying

(B.) the mod date should not change if you want to change the default application (for opening *.pdf or any other kind of files)

In Windows, A and B seem to be what happens, and this forum (and others) are full of folks who want it to “just work” as easily on the Mac. sigh…

On the other hand, some people would say that when you copy a file you are really not creating a new file but you you just making a copy. And by definition, a copy should be identical in all aspects, including file creation.

In my view, the real solution is to add a new option to cp that will preserve the creation date. Apple PLEASE do that for those who believe a copy should be identical in all aspects.

And while you are at it, Apple please fix the symlink ownership bug. When you copy a symlink using cp, the symlink ownership is NOT properly copied. (Still exists in 10.4.11)

But many applications don’t preserve the creation time when you save the file over the original. They write to a different file name, then rename the new file over the original. Or, they rename (or link) the original to a backup name.

This is so if you run out of battery (or any other crash) when saving, you don’t lose the file. On the next boot, you’ll get the old file, or the new one, but at least you will get one of them.

If a program just writes over the original file, and there’s a system crash, you lose both versions – very bad.

What this means is, in general, creation dates are often not preserved when clicking “Save” in applications, especially good ones ported from other unixes, unless the application has OSX-specific code to copy the creation-date attribute.

I agree the creation-date attribute is sometimes useful (but also that EXIF date in a photo file is more relevant). But it does require application support if you want to preserve it between saves.

I do not have the skill to write scripts. Could you post or send me the script which you use?

Thanx Al Maloney

I just want to preserve two pieces of data: 1) the File Name Creation Date 2) the File Contents Last Change Date.

That should not be so hard to do.

A user should not depend on the ctime of a file for any purpose as it’s designed for use by the filesystem and nothing else. It is immutable.

However, this is not to say that there shouldn’t be some form of metadata for tracing a file’s creation in user land. I believe that the confusion here is in that the ctime is being confused as the file’s “Creation Time” when, in fact, it’s the inode’s “Change Time” (man 2 stat). The HFS attribute ATTRCMNCRTIME (man 2 getattrlist) should be a separate entity and not tied to the BSD ctime entity. As such, the use of the HFS CRTIME attribute could happily coexist with the BSD ctime.

I’m digging into this further, but I believe that an understanding that the BSD ctime entity isn’t the same as the HFS CRTIME attribute will lessen the animosity between the two camps.

Tim

Aside from photos, creation date ordering is very useful for keeping track of audio files that are recorded in sequence (if you don’t want to go though route of names like ‘[YYMMDDhhss]-[file name]‘) It’s very annoying that LAME does not preserve creation date information somehow. I have a bunch of files that are so ordered – fortunately, I put the date and month in the name, but the creation time information is still lost.. (which I care about, in this instance)