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)

So for a photo taken on August 2, 2007 at 2:45:02 PM with my LZ2 camera, the filename becomes:

20070802@14450201-LZ2.jpg

The ‘01′ at the end of the numbers says that this was the first picture taken during that second of the day (my camera can take more than one picture per second). Not readable enough for you? Then put hyphens in: 2007-08-02@14-45-02-01-LZ2.jpg

Still not readable enough? Use month names: 2007-Aug-02@14-45-02-01-LZ2.jpg

The reason it’s year, month, day and not some other order like month, day, year is so things will sort properly.

I can’t imagine this system breaking any time soon.

I managed to preserve the creation dates when I copied his files from the old OS 9 server to OS X Server. But now when one of his workers opens a file from the new server on her desktop (via a mounted sharepoint) and closes it without saving any changes made to it, the document’s creation date changes. Essentially, she does a Save As and closes the original document without saving it. Or she copies and pastes text into a new document from the original document and closes the original one without saving.

One would expect the new documents she created in both examples above would get new creation dates. But not the original document, which she was just using as a template.

I’m not sure if this is related to the copying issues described in this discussion. So forgive me if I went astray. But if any of you can shed some light on this dilemma, it would be deeply appreciated. In any case, thank you all for your varied takes on this issue.

In light of this, there’s little sense in testing with files that have identical creation and modification date…

Turns out there’s nothing new; cp -p doesn’t preserve creation dates on HFS+. The whole FAT32 issue is irrelevant in this context.

cp -pR mySrcDir/ myDestDir/

will replicate the creation dates and modification dates, as shown by the Finder [edit: this is incorrect, see my answer below -maurits]. I would hope the same would happen with 10.4.x …

As for FAT32, it does indeed have creation, modification and [last] accessed times/dates (at least when using LFN).

As a side-note, I’ve been resorting to transfering my files via network to my Linux boxes, from which I can safely do “cp -pR” to transfer the creation files over my portable FAT32 drives. A bitch, I know, but if you gotta have it… A smaller note: Linux also does not preserve the directory creation times across FAT32 (arggg), only file times. One day I’ll hopefully take a look at the code and try to fix that, or at least understand why!?

With respect to FAT32, I don’t know that file system well enough. Are creation dates even supported under Windows?

One suggestion above was to make an archive for the files and keep that. Very annoying and simply useless when one deals with huge files (think movies here), because 1) it takes TOO long and 2) it requires at least 2x the space!

Now the trick I came up with which worked for me, but was soon abandoned because of the above said problem, was to create an archive (with the contextual menu) or a tar file of the contents and use the (if I recall correctly) built-in archive tool to unpack it on the FAT32 volume with success. It would never preserve the creation dates for the directories, but it worked for files. You also cannot use the tar tool to uncompress, because it’s the one that doesn’t preserve the time stamps :( And that’s why the author couldn’t get the tar method to work.

Now as far as what Peter da Silva says “The creation date should be taken from the file’s internal metadata”, I believe points to the argument that creation date is esoteric to the filesystem, in which case WHY is it even shown anywhere ??? It’s exactly its ability to be viewed and/or used by the user, which makes it useful, and contradicts this view of it being esoteric filesystem material.

I see two sensible positions:

1) file/inode creation date/time is an esoteric part of the filesystem, in which case it SHOULD NOT BE SHOWN IN THE FINDER (or even go as far as removing it from ls, etc), but subsituted with the in-file creation time, if it’s available (images from cameras will have it, yet most other file formats lack such provision), or not be shown at all. This should force tools and file formats to adopt metadata formats for themselves (and an accompanying nightmare of multitudes of different formats shall spring forth)

or

2) file/inode creation date/time is not an esoteric part of the filesystem, but USER METADATA, in which case it should be shown by the Finder, and should be preserved when the contents of the file have not been modified, no matter WHERE the file exists, or on all exact copies made from it (I believe the author of the blog made this lucidly clear by explaining the dichotomy between the digital and analogue realm)

Since I subscribe to the latter ideology (because I’ve not seen a convincing argument for the former, and I’m one of the almost bearded types) I’ll finish this off by asking: has anyone else found a way to copy files (and keep in mind, large files not suitable for a compress + then decompress method) to a FAT32 volume while preserving creation dates?

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. The date at which the file was copied from the camera to your computer is just as accidental as the date the file was restored from backup.

For the businessman who is attempting to use the creation date of the file to establish a legal case: I wish you luck. If you care, maintain your documents under a change control system, or include dates in the documents themselves, and if you care about the legal status of the documents maintain a copy on your attorney’s servers.

Metadata that is relevant to the user should be maintained in the file itself, or (at worst) in its location in the file system. All the HFS+ crack (including HFS+ extended attributes, Spotlight metadata, but not including HFS+ ACLs or BSD flags that are relevant to access control) should be agressively targeted for deletion by Apple, and any tool that depends on its existence (such as Rosetta) needs to be fixed.