File Creation Dates on Mac OS X: Clash of the Cultures
June 27th, 2006
Yesterday, an interesting discussion (via Avi Drissman) about file metadata began on darwin-dev. It all started with a question about the information that tar stores in the ._xxx AppleDouble files, but then quickly digressed into a general discussion of file metadata and file creation dates in particular.
File Creation Dates
For those who haven’t followed my blog, I have been occupied with some metadata-related discussion recently. In an earlier post, I gave an overview of the different classes of metadata that are attached to files on Mac OS X, and showed that among others, Apple’s command-line tools and APIs have some serious issues with the preservation of metadata when copying files; the common denominator being that the file creation date is never preserved.
Jordan Hubbard’s Stance
Now, returning to the discussion on darwin-dev: at some point, Jordan K. Hubbard chipped in a very interesting remark, which probably explains the shortcomings of Apple’s tools. Jordan is famous for being one of the founders of the FreeBSD project back in 1993, and Apple has been lucky to hire him a couple years ago as an engineering manager working on BSD technologies. Here’s an excerpt of what he said:
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.
Basically, Jordan claims there is no problem at all — throwing the creation date away when copying files is just OK.
A User-Friendly Definition of Creation Date Semantics
I strongly disagree with that position, and will bring forward some reasons why preservation of creation dates is the right thing to do.
First of all, I haven’t been around in the computing business for as long as Jordan has, nor am I a professional, nor do I have such great experience in designing operating systems; so please bear with me if I am overlooking something significant.
Essentially, the behavior of creation dates is a matter of definition. Definitions cannot be right or wrong, they can just be sensible or useless. Hence, the question will be what the most useful behavior is. Let’s look at the following illustrative example. Say I have a picture taken in 2002, which I downloaded from my camera at that point. So it’s got both its creation date and its modification date (identically) set to that point in 2002. At some point in 2005, I find that the picture is turned 90 degrees because I had turned the camera to portrait orientation, so I go ahead, turn the picture by 90 degrees back in Photoshop, and save the file. Result: Creation date still 2002, modification date 2005. Fine. Now, in 2006, I start reorganizing my files, maybe copying files from one partition to another, duplicating some files for other projects, etc. According to Jordan’s logic, the copies of my picture should have a creation date of 2006, which is when the new inodes were allocated.
From a user perspective, this doesn’t really make sense. The copy of the picture still contains a picture that was taken in 2002, so a naive user should still expect that to be reflected in its creation date. After all, the contents of the file have not changed by the fact that I made a copy of the original file, and even less so the time at which the contents were created. By a simple look at Finder’s File Info window, one can still tell that the image was taken in 2002 if creation dates are preserved.
Why Creation Dates Shouldn’t Be Second-Class Citizens
Now, Jordan’s definition of creation date as a “filesystem internal” beast is consistent (irrespectively of why a new file is created, it’s creation date is always set to now) and easy to implement, but IMO it doesn’t make sense for most use cases. Where is the point of storing the time at which a particular inode was created? What’s the added value of that information for the user? In the “real”, analog world, where it’s impossible to clone things, it makes sense to attach a new creation date to copies of things, because the copy is indeed newer, so it may have a larger lifetime from now on, etc. etc.; but the digital realm brings with it the possibility to clone data such that the copy is indistinguishable from the source, and thus it intuitively makes sense to associate the creation date with the contents of a file, and not with such a technicality as an inode.
Everybody’s been fine without a “filesystem internal”, as Jordan calls it, inode creation time, and I doubt there’s any direct technical use for it. But content-centric creation dates have a direct informational benefit for users. What I’m suggesting is to accept creation dates as first-class citizens in the metadata family, and to have the BSD-level tools support the preservation of creation dates throughout.
Fortunately, Mac OS has a long history of asking what makes sense for the user, and putting the user perspective first, not technicalities. Starting with the first Macintosh file system released in 1984 (MFS, which evolved into HFS a year later), Apple has supported creation dates as full-blown file metadata. I don’t have the hardware to check, but at least for the limited number of OSes that I’ve personally used (going back to OS 7.0), I recall that the Finder has always displayed the file creation date in the File Info box, and also preserved the creation date when copying files. Just what I would consider user-friendly behavior.
Now I’m not an expert in Unix history, but as far as I can tell, support for file creation date is only very recent in most Unix variants, and also the file systems traditionally used by Unix-type systems don’t support creation dates. That seems to be mostly because the Unix founders considered creation dates a flawed concept in itself. Also, creation dates have often been confused with an inode’s ctime, which traditionally denotes the time at which the contents of the inode itself such as the permissions have been changed. (See this excellent blog post bringing light into the confusion). Anyway, in times where cat < a > b may not be sufficient anyway for copying files (speaking of extended attributes, resource forks, etc.), the outright damnation of creation dates seems to cease, and creation dates make their way into systems such as FreeBSD.
While the technical perspective of Unix system programmers probably favors a point of view similar to Jordan’s, I guess it’s correct to say that Unix doesn’t have much tradition in handling creation dates, whereas in Mac OS creation dates have lived a peaceful existence for 22 years at least. So even if Mac OS X’s BSD-level tools were to define things such that most other Unix hackers wouldn’t immediately agree with it, there’s not many expectations to be violated on the Unix side; however, the current neligence of creation dates makes Mac OS users suddenly lose a behavior that they’ve learned to appreciate over a long long time.
The Finder still continues to preserve creation dates — so I fail to see why the command-line equivalent of a Finder file copy, cp -Rp, should have different semantics. We’re of course not even talking of cp, by default, preserving creation dates, but of cp with the explicit -p option given, which essentially tells cp to preserve as much file metadata as possible. The same is true for ditto (which is fundamentally broken in 10.4, anyway) and rsync -aE (which is also broken, in other ways). Even in the case that nobody hears my pleas about the preservation of file creation dates in normal day-to-day file copying scenarios, it should still be possible to roll a file backup solution with at least one of Apple’s built-in tools. Currently, there is a formidable market for third-party backup tools, because Apple does not provide a robust and complete file cloning engine.
Conclusion
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; also, it may be weird to see that Mac users care about such subtleties (Windows users definitely wouldn’t), but the resonance to my earlier blog posts and on dawin-dev has shown that quite many do.
So, Apple, please, have mercy with the old-time Mac users and fix the broken behavior of the BSD-level tools and APIs. Please continue making Mac OS X the most user-friendly Unix system there is! For the record, this is Radar 4506951.
P.S. The irony with Jordan’s view is that the BSD tools currently don’t even behave as he proposes — upon file copying, the creation date is set to the modification date of the file. Now that’s the most illogical solution of all IMO. What’s the worth of creation dates in such an environment? Setting it to zero would even convey more information about the file’s past…
33 Comments Add your own
1. Dan Shoop | June 27th, 2006 at 04:37
As you point out Jordan’s position is inconsistent, but not in just the sense that the Finder supports creation dates (always has) and therefore this is obviously the intended Macintosh behavior for copying files, that is copying them with their creation date intact.
When cp, et cetera, copy files to foreign filesystems (anything not HFS, including remote filesystems, AFP excluded) it’s supposed to create an Apple Double style file pair, with the data stream part in the ‘file’ file and the Mac specific stuff in a ‘.file’ file. The format for this dates back over a decade. And it includesm quite specifically, the creation date in the ‘.file’ file so that when restoring the file pair to a Mac it comes back “just the same”.
So it’s not just a Finder behavior, but a well agreed upon precept of metadata to be preserved how Mac files copy.
Also try the following:
tar -cvf - file | tar -xvf - -C newdir. It will also preserve the creation date.Creation date is clearly not “filesystem internal metadata” on a Mac. Nor is it specific to the inode of the file as it’s created.
2. Jon W. | June 27th, 2006 at 05:24
I think some of the dissonance here stems from what I’ve heard called a “leaky abstraction.” Whereas a typical user sees virtual files in virtual folders, a bearded Unix guru sees inodes and directory entries.
When I read Robert Elz’s reply on netbsd-users, I had no problem deciding which operations should set the creation time. As I tried some of them, however, I began to see the problem: the inode does not always change when I expect it to. For example, output redirection replaces all of the data, so I assumed that it would replace all of the metadata. In fact, if a file of the given name already exists in a directory, the “new” file inherits the inode, creation time, and access time. I assume this is some kind of performance optimization. Ideally, it would be one that you could tweak, like mounting a file system with the noatime option.
One of my other peeves is that browsers store the source URL of downloaded files in the fragile .DS_Store. Not even Finder preserves that when you copy the file.
I’m not impressed by Jordan Hubbard’s suggestion on darwin-dev that preserving metadata “might be the wrong thing,” but maybe my beard just isn’t long enough.
3. maurits | June 27th, 2006 at 05:36
Jon: thanks for your valuable comments. “Leaky abstraction” is indeed a good term… :)
As for output redirection into an existing file, I would think that it makes sense from the naive-user perspective (which I’ve been taking) that the creation date is that of the old existing file. You’re just pasting new content into an old, existing container. In any case, I’m sure it’s possible to come up with arcane border cases involving output redirection and whatnot. I’m not saying that the traditional MacOS behavior is absolutely foolproof. But the fact remains that Aunt Tillie has no understanding for why her pictures are suddenly no longer created in 2002, but in 2005, just because she copied them in 2006 (and happened to do a modification in 2005).
Browsers don’t store the source URL in the .DS_Store (AFAIK). That’s one of the few rare cases where the information is actually directly written into the Spotlight database. See the discussion in my earlier post.
4. maurits | June 27th, 2006 at 06:40
I should probably add the following to avoid the obvious reply: While it would be highly surprising if Aunt Tillie typed stuff like
cp -Rp sourcFile targetFile, the reference to her is still valid. She might use a tool (such as CarbonCopyCloner) that calls Apple’s tools or APIs; and from my experience I can tell that Macintosh power users (who might be suspected of usingcpand friends themselves) are atypical in the sense that they often argue like Aunt Tillie when it comes to questions of user experience.5. Alastair | June 27th, 2006 at 12:16
Summarizing Jordan’s reply, he’s basically agreeing with you but saying that fixing it will be hard.
Reading between the lines it seems that Apple has thought about this a lot.
6. John Fieber | June 27th, 2006 at 16:40
I don’t think creation date can be sensibly defined in a context independent fashion. If I take a picture, I can consider the creation timestamp as the moment I take the picture. Then it goes into my computer, where you can convincingly argue that that the timestamp of the shutter release should be preserved as the creation date. Then I make a slight crop, and adjust the tonal balance a bit. You could still argue for preserving the original shutter release time but not as convincingly.
Then I do something more drastic, say paint out a person or copy some other images in to make a photo-montage. Now what should the creation date be? I could argue that there should be a list of dates: one for the shutter release time of each image in the montage and one for when I put them together in the same image.
Creation date semantics cannot be separated from a particular context. The context the OS is using (inode creation) may be in conflict with the context the user would like, but the OS does not have access to the context the user would like, say image manipulation. Only a domain-specific application can do something sensible there. In the photo case, we have metadata standards like exif to represent the desired creation date semantics.
7. maurits | June 27th, 2006 at 18:39
John: your point is well taken. I’m not saying that creation dates per se are the universal solution in all contexts; if you want complete history, for example, you’d need a version control system.
But anyway, let’s be precise: I haven’t made any normative statements about what the semantics of creation date should be for applications that edit files. That is indeed a question of each individual application (but we have to admit that creation dates do exist, and they are used, even if the semantics may depend on the context). My proposition is just to conserve whatever creation date a given file has when copying it. Full stop.
8. Teva Merlin | June 29th, 2006 at 05:49
John: in the example you give, it seems to me that if you save your photo-montage in the same file as the original picture (overwriting it), it probably means you see it just as a modification of the picture — in which case, it is normal that the creation date does not change, only the modification date does. Whereas if you see your montage as creating something new, independent of the original picture, you will probably want to save it as a new file — which will have its own creation date.
9. donald Hinkle | July 18th, 2006 at 15:40
I just discovered this loss of both modified and creation dates as my wife copied files to a flash drive. I’m shocked that apple could let this happen. it seems very important data to preserve to me. i hope someone comes up with a functioning work-around very soon.
10. Dave Nelson | December 11th, 2006 at 06:47
On what seems to me a highly pragmatic note: this creation date seems very important. Let’s say I am a highly accomplished businessman and have a theoretical competitor who is interested in the top-secret business plan (regarding some products that I am trying to obtain patents to) it has taken me a full year to complete. Let’s say this competitor has a savvy hacker on staff and said hacker figures out how to gain access to my server and desktops. Hacker King copies the files to his computer, deletes my existing copies on server and desktops, and if I am rich enough to have a tape backup connected to the server (but, of course, the tape backup has a different creation date - say today), he manages to also delete that tape. Let’s say for argument sake, that ends the trail I have to prove I am the author of that plan. My competitor’s hacker then contrives a scheme whereby he pre-date creates the file (can this be done?) and then begins to take me on a litigation nightmare ride regarding the aforementioned patent-pending products.
Admittedly, I am no Unix geek, and until I decided to do some research on my backup procedures, which needed serious upgrading, I knew almost nothing of this “metadata” concept as of yesterday. But I am concerned because so much of business is conducted in “byte” format and many plans are only ever recorded as such. I have always used Macs and creation date has been appreciated by me. I have written many revisions and it has helped me keep track of things. If my hard drive crashes and my backup doesn’t preserve this info it could cause trouble. Also, per the example above, it also becomes difficult to enforce copyright issues if you can’t prove your creation date and authorship. Owning a hard copy doesn’t hardly seem proof enough anymore.
11. switcher braucht sehr dri&hellip | December 14th, 2006 at 14:37
[…] permalink Hi Zacks und kawaii, ich habe jetzt einige Zeit für euch im Netz herumgesucht, da meine erste Antwort wohl etwas übereilt war. Ich hoffe, ich mache das wieder gut, indem ich euch jetzt viel zu lesen gebe - und zwar diesen Beitrag. Der Text ist auf Englisch und (inklusive aller Kommentare, von denen einige - wenn ich das richtig verstehe - Unix-basierte Lösungen anbieten) sehr lang. Er wird auch euer Problem nicht lösen, aber er verschafft immerhin einen interessanten Einblick in die Hintergründe. __________________ LC II / Performa 6300 / Power Macintosh 7600 / iBook G3 Blueberry [adoptiert vom AT-User "bund"] / Power Mac G4 (MDD) / Mac mini PPC / iBook G4 14" […]
12. Thomas | April 7th, 2007 at 14:07
Dan, you say: Also try the following: tar -cvf - file | tar -xvf - -C newdir. It will also preserve the creation date.
Not on my system (MacBook Pro running 10.4.9, installed about a week ago). It preserves the modification time but not the creation time. Is there another switch that you have forgotten to mention? I searched the man page but have not found anything.
Coming from Linux (and being a one-week-MacOS-noob) I am shocked to see that almost all prrograms I have tried fail to make verbatim copies of files. I am one of those with the “photos use case” and the creation date looks like a nice property. Unfortunately as soon as you need to restore a backup, they are probably gone :(.
And another :( for that crap being still not fixed a year after this blog entry was posted.
13. Hwin | April 10th, 2007 at 19:01
There’s actually areally simple fix for preserving original creation dates on files. Ctrl+click/right-click on the files you want to move, and in the contextual menu that pops up, select ‘create archive’. The archive will have all the original metadata, and can be moved freely, keeping it attached. A bit annoying, but it works and is by far the least hassling.
14. Peter da Silva | April 24th, 2007 at 13:06
“Let’s look at the following illustrative example. Say I have a picture taken in 2002, which I downloaded from my camera at that point. So it’s got both its creation date and its modification date (identically) set to that point in 2002.”
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.
15. Adonis | June 7th, 2007 at 06:19
Very interesting blog topic, because simply I was likewise annoyed by the inability of Mac OS X (since early 2005 to be honest) to preserve creation dates when specifically using the -p option in cp. Now, it works fine on HFS volumes [edit: this is incorrect -maurits], but not on others, such as FAT32.
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?
16. maurits | June 7th, 2007 at 06:34
Adonis: thanks for your comment. You seem to imply that cp -p preserves creation dates on HFS+. Correct me if I’m wrong, but that’s not the case, at least in my 10.4.9. The original problem that I blogged about still exists.
With respect to FAT32, I don’t know that file system well enough. Are creation dates even supported under Windows?
17. Adonis | June 7th, 2007 at 06:46
Yes, in 10.3.9 (that’s what I have infront of me), on an HFS+ volume, doing this:
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!?
18. Adonis | June 7th, 2007 at 06:48
In case of confusion: when I say “times” or “dates” or “file times” or “file dates” or “directory times” or “directory dates”, I mean date & time stamps where available.
19. maurits | June 9th, 2007 at 01:08
Adonis was confused by the fact that Apple’s tools set the creation date to the modification date upon copy.
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 -pdoesn’t preserve creation dates on HFS+. The whole FAT32 issue is irrelevant in this context.20. Ron | June 13th, 2007 at 06:27
I’m new to OS X 10.4.9 and OS X Server 10.4.9; I defected from the Windows world. I set up a network for a client who is having big problems with creation date issues. He relies on them as a way of tracking client documents and origination of templates and has been doing so since adopting Macintosh more than ten years ago.
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.
21. Dan | August 7th, 2007 at 03:45
If the problem is keeping track of when photos were taken, do what I do. I have a script that renames each file, using as the file name the time the picture was taken, and the camera that was used.
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.
22. maurits | August 7th, 2007 at 04:09
that I call poor man’s metadata :-) Would be nice if we didn’t have to bother witch hacks like that. It’s extremely robust though, that I have to admit.
23. Jim Witte | August 26th, 2007 at 22:49
An interesting fact is that the touch command will actually set the creation date (and mod date) if the current system time is before the date you give touch. Is this a bug, side-effect, or undocumented feature?
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)
24. brumeister | November 19th, 2007 at 18:31
Sorry to come so late to this party, but I must add the following:
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
25. brumeister | November 19th, 2007 at 18:36
In the second paragraph of my post, the constant definition ATTR CMN CRTIME should have underscore characters between the three sets of letters. The BLOG software apparently perceives underscore characters as implying italics…
26. Aunt Tillie | December 2nd, 2007 at 22:50
Aunt Tillie here. I don’t do scripts, and in any case I want the filename to have a mnemonic utility for me, relating to the contents of the file, in English.
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.
27. Al Maloney | January 31st, 2008 at 17:03
re: 21 dan
I do not have the skill to write scripts. Could you post or send me the script which you use?
Thanx Al Maloney
28. Jamie Lokier | February 3rd, 2008 at 16:45
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.
29. Rob | February 7th, 2008 at 00:43
It is really a matter of perspective. Some people would say that when you copy a file, you are creating a NEW file. A new file should have the creation date set to the date the file was copied.
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)
30. roscomouse | March 29th, 2008 at 18:23
I’m Aunt Tillie’s older brother, and I’ve been using Macs since the beginning of time. Now I have G4s and a G5 running 10.4.11 and my problem is that all the files on my LaCie Gigabit Ethernet Disk with embedded Windows XP suddenly change both the CREATION TIME and the MODIFICATION time on ALL files by exactly one hour. This creates havoc when backing up to my to Linux-based network drives. My first though is that it had something to do with the change in Daylight Savings Time, but the same thing happened a short while after copying all my files from one drive to the other so that they would again have the same dates and times. Can anyone here help to preserve my sanity?
31. ncprius2 | April 16th, 2008 at 04:39
A related can of worms is that there is no date associated with the resource fork. This makes life difficult for backup software trying to figure out if the fork changed, like rsync3 used in bombich CCC.
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…
32. ncprius2 | April 16th, 2008 at 04:52
To Aunt Tillie’s older brother: roscomouse | March 29th, 2008 at 18:23 with the 1-hour issue.
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?
33. Dave | June 12th, 2008 at 06:10
Disclaimer: I didn’t read all the comments….
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.
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed