File Creation Dates on Mac OS X: Clash of the Cultures

June 27th, 2006

burnt computer

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…

Categories: hacking, macosx, unix

Tags: , , , , , , , , , ,

54 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 using cp and 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 -p doesn’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

    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.

    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.

  • 34. Martin Andersen  |  August 20th, 2008 at 19:19

    I wonder how current this is. I recently got a Mac with Leopard. Apart from the included Time Machine providing a built-in backup facility, Which I have not tried for lack of an external drive, I note that the images that I copied across the network from a PC, and then copied to iPhoto, all have their original Creation Dates. But if I try a cp -p, then indeed the Creation Date is reset to the modification date. Being a copy, that is understandable. The man page specifically leaves out mention of the Creation Date. Maybe it is a missing feature, as it would seem natural that it should preserve the Creation Date with that flag set. Else have another flag that does preserve it. Doing a mv, the Creation Date is preserver. So the system as a whole seems to respect the Creation Date in Leopard, though I have only limited experience with that. Conventional Unix tools don’t usually support Creation Date, as UFS doesn’t support it. And Mac OSX is kept in sync with FreeBSD. I did read in a mailing list that an updated version of UFS supported by newer versions of FreeBSD does include support for Creation Date, and they have updated tools like ls to support it. In experimenting with a commandline metadata tool called exiftool, I found that its -P flag which preserves the Modification Date did not preserve the Creation Date, instead it was set to the Modification Date. So I experimented with touch, and found as mentioned that if you first set it to the Creation Date, followed by the Modification Date, you get back the original dates, since when setting a date older than the Creation Date, they are both set the same, but newer and only the Modification Date is set. So touch along with other commandline tools needs updating too. But OSX wasn’t designed for terminal nerds, and as long as the graphical applications behave, Aunt Tillie won’t mind.

  • 35. Daniel O'Leary  |  December 28th, 2008 at 21:59

    I encountered the problem of “BAD” date/time information back in 2006 also. I believe that an exact copy of a file (a binary comparison is successful) should have the same time and date information as the source file. If the contents of file are subsequently modified , then update the modification date to reflect the time and date that the modified file is resaved.

    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.

  • 36. EvanED  |  February 24th, 2009 at 23:34

    I know this is a very old post, but I still thought I’d chime in since I have a strong case of “but someone is wrong on the internet!” syndrome. ;-)

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

  • 37. maurits  |  February 25th, 2009 at 00:16

    Evan – thanks for your insightful and well thought-out comment. I especially appreciate that you address some of the prior comments, which I haven’t bothered to answer to yet. I pretty much agree with all of what you’ve said, wouldn’t know what to add.

  • 38. john v  |  March 7th, 2009 at 15:53

    Would a retro-but-effective answer to preserving file creation dates in backup be to use an OS9 box to do the file transfers to archive?

  • 39. Deric  |  May 11th, 2009 at 16:48

    With all the high level of knowledge posted here, I kindly ask, can someone tell my in simple English, how is it possible in MAC OS X, when using the finder, that a file’s creation date be newer than the modification date?

    We are miffed at our district.

    Thanks Deric

  • 40. SR  |  June 15th, 2009 at 16:14

    There is a logical mistake in the high level view of the problem. In the first place you choose wrong metadata type to track. File creation date is not what you want to look at to know when a picture was taken (ex. picture taken in May 2002 can be copied from memory card in 2006).

    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.

  • 41. Guido Tonini  |  June 19th, 2009 at 09:23

    I completely agree with the need to have a true semantic value associated with the creation and modification dates. The problem has to be extended to other file formats in order to appreciate its weirdness.

    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.

  • 42. Leonardo  |  March 22nd, 2010 at 13:19

    I have a new question about dates. It’s about the st_ctime, or otherwise said inode-change-time, or fsCatInfo.attributeModDate. I am developing an application on MacOS X (for 10.5.8 and 10.6) and I need to backup some file with it.

    Let’s suppose I have just done a backup. I have copied the creation and modification dates from the source file to the destination file. Well. Since the stctime cannot be modified by the user nor by the developer, the destination file just copied gets the stctime date of the backup; exactly the time I have copied that file.

    Later on I launch the backup again, and my backup application detects that the destination file has a st_ctime date more recent than the source file one, so it thinks that it needs to copy the attributes (only the attributes, not the contents) from the destination file to the source file. And this is wrong!

    So, I think that after I copy a file, I should be able to set the destination stctime date equal to the source stctime date. Actually I don’t know how to do. Do you know a way to do that?

    I even thought to touch someway the source file such a way the system updates its stctime to the current time, so if do that just a nanosecond after I have copied the source file to the destination, I could end with a stctime source date almost equal to the destination file one. Then at the next backup I could check whether the dates differ for 1 or 2 seconds. But sometimes I can’t do that because in some case, the source file/folder is readable only, not writable.

    Someone told me that I could temporary change the system date, touch the destination file (e.g. with FSSetCatalogInfo) and set back the original system date. But I find this risky and, most of all, only the root user can change the system date.

    Of course I have already and unsuccessfully tried with FSSetCatalogInfo & kFSCatInfoAttrMod, and even with setattrlist & ATTRCMNCHGTIME.

    Any suggestion?

  • 43. Sl320 Taillight Benz Tail&hellip  |  May 20th, 2010 at 06:36

    [...] 123456789101112131415161718192021222324252627282930Sl320 Taillight Benz Tail, Sl320 Mercedes Benz SlSl320 Taillight Benz Tail, Sl320 Mercedes Benz Sldiscount slk55 amg mercedes benz sl320 sl320 factory 300sl mercedes benz sl320 part headlight assembly sl320 sale search sl63 amg 2002 benz s430 accessories mercedes sl320 sl320 aftermarket coupon mercedes benz sl320 sale sl55 sl63 amg sl320 outlet mercedes benz sl320 bulb sylvania fog light sl320 air sl320 engine sl320 bulb e200 sl320 aftermarket slk32 cl65 amg sl320 half sl320 parts headlight assembly sl320 headlight cls55 amg mercedes benz 240d sl320 part 1995 mercedes benz rear view mirror 1997 mercedes benz sl320 price sl320 taillight oem sl320 headlight wiper volvo c70 headlight door w124 sl320 sl500 sl600 sl320 reviews mercedes benz sl sl320 bulb turn signal bosch headlight sale sl320 sl65 amg part used mercedes benz sl320 clk55 amg sl320 free 1995 mercedes second hand mercedes benz sl320 dvd sl320 mercedes benz sl320 car sales sl320 ac mercedes benz sl320 replacement cl55 slk32 amg sl320 cooling system 1997 mercedes sl320 adapter 1995 mercedes benz sl320 vehicle 500sl headlight left mercedes sl320 sl320 company sl320 metal halide sl320 radiator bulb e320 sl320 sl500 sl600 1994 mercedes benz sl320 parts brake pads sl320 cars sale 95 mercedes benz sl320 sl55 amg sl320 replacement oxygen fit sl320 used sl65 amg mercedes benz slr mclaren sl320 sale locator sl320 sell automotive sl 1995 mercedes sl320 roadster for sale automatic transmission sale used mercedes benz sl320 sl63 amg sl320 repair there mercedes benz sl320 auto parts sl320 parts 2nd hand mercedes benz sl320 rent sl320 replacement catalog mercedes benz sl500 refurbished mercedes sl320 auto cheap sl320 selling sl320 sale sl63 amg 2009 mercedes benz sl sl320 aftermarket slk55 ml55 amg sl320 discount search sl320 aftermarket new mercedes sl320 model 1997 mercedes 500sl dvd 300sl sl320 1994 mercedes benz sl320 parts sl320 zone parts accessories sl320 sale classifieds sl65 amg sl320 parts game sl320 problems had mercedes benz sl320 part sl55 amg sl320 sale sl63 amg mercedes benz slr mclaren sl320 wholesale cheap sl320 basic camera sl320 model replacement mercedes benz sl320 sl55 amg sl320 warehouse mercedes sl320 parts brake pads sl320 socket 190d headlight auto parts mercedes sl320 sl320 used car sl65 amg sl320 change 1997 mercedes benz sl320 sell replacement parts mercedes benz sl320 mercedes sl320 sale sl63 amg benz slk mercedes benz sl320 central heating auto parts sl320 car benz sl320 part sl65 amg sl500 mercedes sl320 cheap 1995 mercedes benz find sl320 city 500sl parts guaranteed mercedes sl320 1997 mercedes benz sl320 parts spark plug wires sl320 kettle sl320 review classic sl320 replacement 1997 1995 mercedes benz sl320 parts online brake pads best buy sl320 sl320 part replacement slk32 amg sl320 used 1995 mercedes benz traction control clearance mercedes benz sl320 500sl radiator call 1992 mercedes sl320 sl320 lamp 1995 mercedes benz headlight bulb sylvania mercedes benz sl320 190d headlight auto parts sl320 mercedes 500sl Firenza Discount Oldsmobile | S320 Action S320 | Express Clothing Coupons | Avermedia Expresscard Tv | 2003 Mercury Villager | [...]

  • 44. Prizm Ii Metal Detector, &hellip  |  May 20th, 2010 at 10:31

    [...] 1234567891011121314151617181920212223242526272829303132Prizm Ii Metal Detector, 2001 Chevy Prizm Parts Brake CaliperPrizm Ii Metal Detector, 2001 Chevy Prizm Parts Brake Caliper1999 chevy prizm maintenance prizm concert colors prizm vocational used 2000 chevrolet prizm dealer chevrolet prizm wholesale side airbags 1998 chevy prizm mpg 1998 chevrolet prizm lsi prizm lulu prizm theory song 1997 geo prizm wheel cover 1997 geo prizm starter 1996 geo prizm lsi specs heater buy geo prizm prizm part interior prizm gsi for sale prizm cheap cook cost replacement capa certified geo prizm bumper turn signal assembly 2000 chevrolet chevy prizm parts catalytic converter oxygen sensor prizm episode ford geo prizm 2001 prizm floor mats geo metro prizm procite 1994 geo prizm horsepower 4 door sedan buy geo prizm bushwacker chevrolet prizm discount survey prizm projector headlights 1995 geo prizm owner manual prizm free will review 1999 chevrolet chevy prizm parts interior door power locks 1991 geo prizm mpg gsi geo prizm radiator engine oil cooler aftermarket 1997 geo prizm base sedan 1996 chevrolet geo prizm sell prizm floor mats used cars prizm tv audience 1999 chevy prizm body kits 1995 geo prizm sale transmission front wheel drive 1997 geo prizm user manual sale 1994 used geo prizm 2002 prizm sale aveo5 chevrolet g3500 geo prizm aftermarket brake pads model geo prizm accessories coupon 199 geo prizm prizm projector 2002 chevy prizm fuel economy prizm factory repair manuals chevrolet prizm custom prizm restore prizm discharge geo prizm radiator 1997 geo prizm sale below 2000 chevy prizm review 00 chevrolet prizm geo prizm headlight adjustment floor mats part geo prizm accessories autozone 1999 chevrolet chevy prizm parts interior door turn signal 1995 geo prizm toyota gm chevy prizm headlamp assembly geo prizm headlight check bulbs prizm europe express 2500 headlight passenger side s10 blazer chevrolet prizm prizm hood hd geo prizm headlight 1980 geo prizm mpg 1998 chevrolet prizm car listings 1991 geo prizm kit auto body 1997 geo prizm manual auto repair monte carlo parts for sale prizm c3500 car chevrolet prizm 1991 geo prizm starter use used geo prizm hood wheel rim prizm replacement oxygen sensor 4 wire catalytic converter oem 1995 geo prizm cheap engines geo prizm 2001 chevrolet prizm spark plugs 1995 geo prizm diagrams 1991 geo prizm body window tint kits prizm upgrade skimmer 2000 chevrolet prizm lsi lumina prizm part brake shoes vehicle part geo prizm accessories floor mats window deflectors prizm demo large 1992 geo prizm starter prizm customer systems part lowest price 1991 geo prizm prizm graphpad scientific graphing curve fitting 2002 prizm auction chevrolet monte carlo prizm glib replacement geo prizm parts catalytic converter wholesale geo prizm high quality 1990 geo prizm maintenance used chevrolet prizm sedan chevrolet prizm p0171 2001 chevy prizm reviews buying prizm manual buy door handles chevy prizm monster auto bulb geo prizm side marker turn signal assembly 1994 geo prizm performance 1996 1997 geo prizm alternator 1999 cavalier convertible chevrolet prizm Xc90 Review Volvo | Buy Mercedes Benz | 280z Rack And | Saturn Relay 1 | 1990 Mazda B2600 | [...]

  • 45. Camry Cabin Air Filter Re&hellip  |  May 20th, 2010 at 11:56

    [...] 123456789101112131415161718192021222324Camry Cabin Air Filter Replacement, Camry Distributor New ToyotaCamry Cabin Air Filter Replacement, Camry Distributor New Toyota2006 toyota camry se v6 camry prices hood hinge 1991 camry turn signal switch sell 2003 toyota camry xle used 1999 manual transmission toyota camry solara overview 1997 toyota camry headlights pair xenon hid sale car toyota camry solara classified listings camry se forum 2006 toyota camry sell discount 2001 toyota camry front wheel drive 1989 toyota camry exhaust manifold 06 camry body kit yaris pre owned used toyota camry solara toyota camry engine malfunction light used 200 toyota camry hybrid 1999 toyota camry used car camry sale autos toyota venza highlander hybrid 1990 toyota camry radiator exhaust manifold toyota camry 2010 philippines automatic transmission 2001 toyota camry fender 08 camry mpg cheap reply toyota camry 2005 toyota camry for sale in santa cruz 1992 toyota camry timing belt replacement camry part celica timing belt toyota solara 2004 camry headlights 2007 toyota prius recalls camry 2005 camry hybrid 2007 2008 1994 camry projector headlights 1997 camry hubcap 1989 toyota camry engine specs 93 toyota camry headlight oxygen sensor 2009 performance parts toyota camry accessories 2002 solara performance parts camry camry discount replacement headlight assembly 1999 dome light 1994 toyota camry 1989 camry auto parts auto parts toyota camry headlight oxygen sensor t100 sale vehicle camry solara 2009 toyota camry hitch toyota camry autos highlander hybrid 2010 aftermarket parts toyota camry accessories sale 1999 camry toyota solara convertible camry blub 1998 toyota camry exhaust system auto parts 1999 parts toyota camry solara wholesale camry toyota parts 1999 camry solara camry radiator flush remove timing belt toyota camry solara convertible review toyota camry speaker toyota camry midsize honda accord 1992 toyota camry workshop manual toyota camry solara canada toyota camry luggage rack 2007 toyota camry front wheel 2001 toyota camry cargo liner 1996 toyota camry distributor spark plug wires sale 2005 toyota camry solara convertible 1986 camry for sale solara pictures 2002 toyota camry toyota camry master window switch camry exhaust parts 1996 toyota camry repair manual ignition coil sale used toyota fj cruiser camry solara camry real world mpg 1986 toyota camry headlight 2001 toyota struts camry timing belt solara sale 2002 toyota camry highlander hybrid 1999 toyota camry sale philippines camry headlight auto parts free 1995 toyota camry interior door handle 2005 camry speaker covers 1995 toyota camry power steering hose sale toyota prius sedan camry hybrid 2000 toyota camry used car hyundai sonata 1997 toyota camry hood camry tire pressure brakes 2007 convertible colors 2004 toyota camry solara camry reviews 8 passenger installing cold air intake toyota camry parts toyota camry spark plug wires 2009 toyota camry side mirror kool vue 1992 camry thermostat 2004 2009 toyota camry celica supra camry headlight tuning high beams 2001 toyota camry engine used camry hybrid charlotte nc toyota scion thermostat 1996 toyota camry toyota corolla discount camry hybrid warranty 1999 camry fan blower resistor 1994 camry dimensions 1999 camry solara lyrics camry seats 99 camry v6 custom camry bulbapedia want 2007 toyota camry side mirror years 2000 camry in mississippi used toyota 4runner 2003 toyota camry specs nova toyota camry 0 60 Oldsmobile | 380sel Bulb Export | S420 Lighting Slk | Used Jeep Cherokee | Chevy K10 Sell | [...]

  • 46. Trucks Sale Lees Summit, &hellip  |  May 20th, 2010 at 20:34

    [...] 123456789101112131415161718192021222324252627282930313233343536373839404142Trucks Sale Lees Summit, Summit L500vaTrucks Sale Lees Summit, Summit L500vamerrell summit ii premier fuel summit 1992 eagle summit service manual summit refurb built greek mountain summit summit refrigerator frost free stainless steel summit half doughnut hole 1996 ski doo summit 600 north face summit series fake dvd summit cullen reno promo the summit at grand sierra resort circus circus hotel summit horn bulb summit part obama newt gingrich congress summit education inc automobile eagle summit summit pt senator baucus summit design available summit vacations rentals 2010 summit x summit fuel pump real estate sale summit nj watchung mountains 06 ski doo summit x discount the summit at grand sierra resort casino reno comfort inn & suites summit crest summit county utah property sale summit appliance manual used extreme summit mini gbic 10 gigabit ethernet summit motor inn upper darby summit 800 photos ski doo snowmobiles for sale summit lake campground co extreme networks summit 4 summit part charlie rangel health care reform peter roskam summit lighting lamp post summit upcoming hosts summit construction group summit perfect affiliate summit missy pinnacle award new highlander movie radiators summit entertainment lees summit restaurants summit tal look weber summit s 420 celebrity cruises summit mexico complete floorcovering lee summit summit model doughnut hole closing summit compact refrigerator beverage cooler summit discount appliance refrigerator freezer cheap lift tickets snow summit buy summit colorado cove the summit oak ridge karrimor summit cheap walking shoe summit fuel pressure gauge summit sale keystone copper mountain real estate dillon summit management software summit removal nj traxxas summit hard anodized esc colorado springs summit summit demo doughnut hole summit insurance services hospitals summit model chinook summit bivy headlight eagle summit catalytic converter used ski doo summit sale mi keller williams summit colorado rockies summit sd work grill cooking grates weber summit world business summit sustainable development summit doppler respiratory system summit s 420 btu per hour summit appliance ratings houses buy summit nj 1993 eagle summit wagon italian ia summit ice climbing scarpa summit gore tex summit full bipartisan john mccain world summit sustainable development energy efficiency summit ny blenheim real estate lehigh valley grand prix coupon allentown brew works summit climbing gym thai summit auto parts wiring harness summit tire dealers summit headlight assembly rochester security summit substitute eagle summit parts log homes for sale summit county colorado extreme summit list price bargain summit summit electric windsor eagle summit distributor wiring harness 2000 ski doo summit 800 promotion summit racing coupon codes enter summit part chris dodd bipartisan s summit summit part senator coburn health care reform summit 2009 fall summit part robert tom coburn weber summit s 420 gas grill review summit body kit talon ski doo summit exhaust summit health care systems summit partners chuck schumer attitash custom grand summit Mitsubishi Diamante Bulk | 2000 Suzuki Esteem | 560sel Parts Shock | Aviator Radiator Capa | 1991 Lexus Es250 | [...]

  • 47. Panasonic Kx Tg5566m, Ama&hellip  |  May 21st, 2010 at 13:44

    [...] 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859Panasonic Kx Tg5566m, Amazon G55 Amg PricesPanasonic Kx Tg5566m, Amazon G55 Amg Pricestoshiba qosmio g55 9600m gt g55 amg adoption hd radio g55 amg auction 420sel aftermarket 1987 mercedes benz cl55 g55 amg g55 amg seats leather g55 amg car buy used g55 amg lamp recirculating ball steering g55 amg used buy specs g55 amg pt 2010 mercedes benz g55 amg repair click mercedes benz g55 amg headlight rear fog lights garage door opener g55 amg bulb public mercedes benz g55 2010 ml63 amg g55 amg 2009 mercedes benz alloy wheels buy g55 cl65 amg mercedes benz slr mclaren mb g55 amg g55 amg speed automatic transmission 15.6 g550 lenovo g550 specifications g550 replacement save mercedes benz g55 amg 2010 land rover range rover 2003 mercedes benz g55 automotive g55 amg sale specs mercedes benz g55 replacement clk55 cl55 amg 2009 mercedes benz g55 sale bi xenon headlights 2003 g55 amg listings buy g550 gulfstream aerospace g55 amg 2nd hand specs g55 amg brake light buy g55 amg new auto g55 amg zone hamann g55 amg part new mercedes gz mg555 price g55 amg installation discount g55 amg sheet music mercedes benz c class mercedes benz g500 radiator g55 amg g wagen mercedes benz g55 sale ml63 amg gl320 cdi buy g55 amg looking pre owned mercedes benz 2003 benz g55 2010 mercedes used mercedes benz g500 g55 amg mercedes benz g55 kompressor leather seats g55 amg repair maintenance used mercedes g55 amg for sale specs g55 amg replacement 2004 mercedes benz g55 amg auto parts g55 amg central heating anti lock braking system find g55 amg prices g55 amg cheap mercedes benz dealers download g55 amg vehicle g55 amg lamp carpeted floor mats bmw g55 amg bulb side marker g55 amg pt mercedes benz g class mercedes benz g55 amg radiator direct manifold gasket g55 parts select amg wheels g55 discount ball joint lenovo g550 notebook ride on toy mercedes benz g55 g55 amg taillight mercedes benz g audi g55 amg radiator grille benz g55 amg 2010 mercedes land rover range rover g55 parts mercedes g55 amg factory 2009 mercedes benz mercedes benz g55 brabus alloy wheels g55 amg new mercedes benz g class specs mercedes benz g55 amg g55 amg problems g55 cls63 amg replacement part g55 amg custom interior mercedes benz g 250 g55 amg 2005 mercedes benz g55 discount lenovo g550 g55 amg concert bmw g55 amg baseboard radiator mercedes benz e63 g55 amg gl450 discount ml63 g55 e55 amg 2003 g55 amg specs toyota g55 amg review mercedes benz g55 parts oxygen sensor g55 amg bulb insure mercedes benz s320 radiator window regulator g55 amg g55 amg part accessories interior g55 amg model cars 500sl replacement ml55 g55 amg well g55 stock buy mercedes benz g55 amg dealers price quote g55 amg part buy car truck g55 amg clearance 2009 mercedes benz c240 automotive g55 amg g55 amg prices g55 amg exhaust manifold g55 amg wheels light g55 led bulb g55 amg pet g550 sale private g55 amg discount buy 2010 mercedes g55 changing g55 amg replacement mercedes benz g class g55 amg specs truck pdf g55 amg mercedes benz g55 amg part locking differentials heated steering wheel Planets L300 1 | Volkswagen Cabrio Used | Test Flasher Relay | Reno Bird Reno | Chevrolet Spectrum Radiator | [...]

  • 48. 17" macbook pro black fri&hellip  |  October 2nd, 2012 at 12:27

    17″ macbook pro black friday deals…

    plasticsfuture » File Creation Dates on Mac OS X: Clash of the Cultures…

  • 49. Window Tint Kit – C&hellip  |  September 26th, 2013 at 08:17

    [...] File Creation Dates on Mac OS X: Clash of the Cultures – plasticsfuture Category: AUTOMOBILES Tags: 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, Carlo, Chevrolet, Chevy, Monte, Tint, window, windows Post navigation ← Evan Fischer EVA39972032640 Antenna Handbook polished three mast section Keeper 04223 2 “x 24″ Axle Strap for the transport of vehicles. £ 2,000 CMU with stamped D-rings → [...]

  • 50. Window Tint Kit – C&hellip  |  September 27th, 2013 at 10:14

    [...] File Creation Dates on Mac OS X: Clash of the Cultures – plasticsfuture Category: AUTOMOBILES Tags: 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, Carlo, Chevrolet, Chevy, Monte, Tint, Window, Windows Post navigation ← ScanGaugeE Compact multifunction board computer customizable with Real-Time Fuel Economy Digital Display Garmin City Navigator Detailed major metropolitan areas in Europe card (microSD / SD Card) → [...]

  • 51. Window Kit Tint – C&hellip  |  October 7th, 2013 at 15:36

    [...] File Creation Dates on Mac OS X: Clash of the Cultures – plasticsfuture This entry was posted in AUTOMOBILES and tagged 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, Carlo, Chevrolet, Chevy, Monte, Tint, Window, Windows on September 29, 2013 by ADMIN. [...]

  • 52. Back and rear Window Tint&hellip  |  October 18th, 2013 at 06:24

    [...] File Creation Dates on Mac OS X: Clash of the Cultures – plasticsfuture Category: AUTOMOBILES Tags: 2003, 2004, 2005, 2006, Back, Chevrolet, Chevy, Rear, Tint, Window Post navigation ← TMS Universal Red Handlebar Hand protection grids for Honda Motocross Off-road ATV Dirt Bike Dualsport Motorcycle MX XL XR CRF 200 250 350 400 450 500 600 650 XtremeMac InCharge X5 30-pin iPod / iPhone / iPad → [...]

  • 53. Window Tint Kit – C&hellip  |  October 18th, 2013 at 09:19

    [...] File Creation Dates on Mac OS X: Clash of the Cultures – plasticsfuture Category: AUTOMOBILES Tags: 2003, 2004, 2005, 2006, before, Chevrolet, Chevy, Tint, Window Post navigation ← Lehigh BPE6100PW-P 100-foot Diamond Braid Polyester Rope, white with red marker Meguiars Gold Class Car Wash Shampoo and Conditioner, 64 oz → [...]

  • 54. Window Tint Kit – C&hellip  |  October 18th, 2013 at 12:24

    [...] File Creation Dates on Mac OS X: Clash of the Cultures – plasticsfuture [...]

Leave a Comment

hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed


Feeds

Categories

Archives

Most Recent Posts