Files/Folders with a Date Created of Dec 31, 1903 8:00 PM.

Question

Level 1

76 points

Files/Folders with a Date Created of Dec 31, 1903 8:00 PM.

So I have this weird occurrence when I open a Finder window and view files on one of my Mac Pro's internal harddrives.

A bunch of the Files and Folders have a *Date Created of Dec 31, 1903 8:00PM*.

The Date Modified is correct.

It's not every file/folder either. Mostly contained in one directory I have with client files in it.

I have:

- Reset PRAM
- Reset SMC
- Verified Permissions, Disks
- Deleted Finder's plist

So far, still happening.

What's interesting is, using the mdls command from the terminal, does not show the 1903 date, but the correct date.

Also, doing a search for the files, no files match when searching for Created Date exactly 12/31/1903....however, I can find a file by searching for the Creation Date that is listed while viewing in terminal using the mdls command.

Any ideas for any experts out there?

Is this just a Finder bug with incorrectly displaying the Creation Date?

-Kevin

Mac Pro 2.66, MacBook 2.4, Mac OS X (10.5.3)

Posted on Jun 20, 2008 7:34 AM

Reply

Answer 1

Best reply

glsmith

Level 3

875 points

Jun 20, 2008 11:08 AM in response to netnothing

Hi netnothing. Interesting problem. Were these files originally created on your Mac, or did you copy them from somewhere else (e.g. a thumb drive, off a file server, etc)?

Your troubleshooting has shown that the HFS file metadata seems to be correct (the metadata is what you're looking at with mdls). When you search for files in the Mac interfaces (like through Spotlight, the Finder, or mdfind from the command line), you're actually searching through this metadata. However, in a typical Unix filesystem, file times (create time, change time, modify time, etc) are usually stored in the file inode. It may be (and I'm just speculating here) that OS X still keeps time in the inode and in the HFS metadata, and that these locations are updated separately by the system. If this is true, it means that there's a chance they could become out of sync due to bugs in the system, originally inaccurate times on copied files, etc.

Or, like you say, this could be a display bug. From the command line, run this:

stat <filename>

where <filename> is one of the files that displays the incorrect time. You will see several timestamps in the output, all coming from the low-level system call "lstat". I'm curious if any of these timestamps have the 1903 date.

Reply

Answer 2

netnothing Author

Level 1

76 points

Jun 20, 2008 11:37 AM in response to glsmith

glsmith, thanks for taking the time to respond.

First, most of these files, I think, were probably created on my XP machine. I'm trying to find one that I know I created on the Mac. I switched to the Mac in Mar 2007. At that time most everything got transferred over. I bought the machine with Tiger, and have since done a clean install of Leopard on it. Most of these files are on a non-startup disk in my Mac Pro.

Here are some results from a file called test.html that is listed in the Finder as having the Date Created of Dec 31, 1903 8:00 PM

From the command: *mdls test.html*

kMDItemContentModificationDate = 2007-09-05 12:14:49 -0400
kMDItemContentType = "public.html"
kMDItemContentTypeTree = (
"public.html",
"public.text",
"public.data",
"public.item",
"public.content"
)
kMDItemDisplayName = "test.html"
kMDItemFSContentChangeDate = 2007-09-05 12:14:49 -0400
kMDItemFSCreationDate = 2007-09-05 12:14:49 -0400
kMDItemFSCreatorCode = ""
kMDItemFSFinderFlags = 0
kMDItemFSHasCustomIcon = 0
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery = 0
kMDItemFSLabel = 0
kMDItemFSName = "test.html"
kMDItemFSNodeCount = 0
kMDItemFSOwnerGroupID = 20
kMDItemFSOwnerUserID = 501
kMDItemFSSize = 0
kMDItemFSTypeCode = ""
kMDItemKind = "HTML Document"
kMDItemLastUsedDate = 2007-09-05 12:14:49 -0400
kMDItemUsedDates = (
2007-09-05 00:00:00 -0400
)

---

From the command: *stat test.html*
234881029 82303 -rwxr-xr-x 1 kevin staff 0 0 "Jun 20 14:23:30 2008" "Sep 5 12:14:49 2007" "Mar 13 20:17:40 2008" "Dec 31 19:00:00 1969" 4096 0 0 test.html

---

So, I see from the stat command that the last date is the Dec 31, 1969 date.

I did this on some other files, and all seem to have the 1969 date from stat.

What I guess I'm most curious is, I can't recall in Finder ever seeing the 1903 date prior to noticing it yesterday. And I'm almost positive, I've always had the Date Created column showing.

Also, with these files that are dated 1903, if I do a Get Info from the finder, the Get Info box just shows Date Created: --

Thanks for your help. Just what I needed to try to trouble shoot this.

-Kevin

Reply

Answer 3

netnothing Author

Level 1

76 points

Jun 20, 2008 11:44 AM in response to glsmith

hey glsmith,

I also noticed that, if for some reason, when using the mdls command to view the metadata, these 2 fields always match:

MDItemFSContentChangeDate = 2007-09-05 12:14:49 -0400
kMDItemFSCreationDate = 2007-09-05 12:14:49 -0400

For example, what I did was copied in Finder that test.html file to test2.html, preserving all the metadata.

I then opened it in BBEdit and made a change, and saved it. When I ran mdls on test2.html, I get the following:

kMDItemFSContentChangeDate = 2008-06-20 14:35:46 -0400
kMDItemFSCreationDate = 2008-06-20 14:35:46 -0400

It changed from the 2007-09-05 from above, to the matching 2008-06-20.

No matter how many time I make a change, these dates always are in sync.

Now, I'm assuming that this file was created on my XP machine, as it suffers from the 1903 date problem.

So I created a brand new file on my Mac called test3.html. Now first viewing this new file with mdls, I get this:

kMDItemContentCreationDate = 2008-06-20 14:38:35 -0400
kMDItemContentModificationDate = 2008-06-20 14:38:52 -0400

Making a quick change, I then get this:

kMDItemFSContentChangeDate = 2008-06-20 14:38:52 -0400
kMDItemFSCreationDate = 2008-06-20 14:38:35 -0400

Clearly, showing the different Create and Modified dates.

Is this an issue of a file created on a non HFS system?

Not sure if this inof helps or not.

-Kevin

Reply

Answer 4

netnothing Author

Level 1

76 points

Jun 20, 2008 11:51 AM in response to glsmith

As another test, I brought over another file from my XP machine, but everything looks ok with that. Finder shows the correct info, mdls and stat also show the correct info.

-Kevin

Reply

Answer 5

glsmith

Level 3

875 points

Jun 20, 2008 1:23 PM in response to netnothing

So, I see from the stat command that the last date is the Dec 31, 1969 date.

That timestamp is basically the start of the Unix epoch time. See this for more information:

http://en.wikipedia.org/wiki/Unix_time

I'm guessing that when these files were originally created, there was some problem setting the create time, and so a default value (the epoch time) was used.

Reply

Answer 6

netnothing Author

Level 1

76 points

Jun 20, 2008 1:34 PM in response to glsmith

Is it possible to change this date in the files inode?

Not that I really want to change it, but is it possible that something, some program, reset this data once on the Mac?

-Kevin

Reply

Answer 7

glsmith

Level 3

875 points

Jun 20, 2008 1:35 PM in response to netnothing

also noticed that, if for some reason, when using the mdls command to view the metadata, these 2 fields always match:

MDItemFSContentChangeDate = 2007-09-05 12:14:49 -0400
kMDItemFSCreationDate = 2007-09-05 12:14:49 -0400

These two attributes will be set to the same value at initial file creation time. Over time, as the file is modified, the MDItemFSContentChangeDate attribute (which is the mtime, i.e. what shows up in an "ls -l") will change. The kMDItemFSCreationDate attribute should never change.

I then opened it in BBEdit and made a change, and saved it. When I ran mdls on test2.html, I get the following:

Yes, I ran a similar test, and to my amazement all the time attributes in the metadata changed!! I used the Vi editor to modify a text file. This is incorrect behavior IMO, and a bug. I also note that "stat" returns the incorrect information as well. I ran some variations on how I changed the file, and saw inconsistent results. For example, instead of using an editor to change the file, I used the command line to append some information to the end of the file (I used "echo blah >> file"), and that change updated the timestamps in the expected way.

I believe there is a pretty serious problem at some level of the Cocoa API that is manipulating timestamps. I'll be filing a bug with Apple on this.

However, to get back to your original issue, I think ultimately what happened was when you originally copied files over to your Mac system, there were problems setting the correct timestamps to begin with...

Reply

Answer 8

netnothing Author

Level 1

76 points

Jun 20, 2008 1:53 PM in response to glsmith

glsmith,

Actually, I'm noticing from my previous post, the contents of the mdls command on those files listed with the 1903 creation date in finder are missing the metadata field:

kMDItemContentModificationDate

This field isn't in the results.

For any files that I create on my Mac, that field does show up.

Does Finder use the inode stored info for it's results, or the mdls data? I'm guessing the mdls data is not stored in the file itself?

-Kevin

Reply

Answer 9

Jun 20, 2008 2:01 PM in response to glsmith

That timestamp is basically the start of the Unix epoch time.

And the 1903 date is the Mac equivalent. If the Finder has no idea what the creation date is supposed to be, it displays that. I seem to remember that there used to be another default date for Apple computers, and that it was the date of the Lisa or the first Apple machine, or Steve Jobs birthday--something along those lines. Unfortunately I couldn't find a reference (I'm sure on some Mac site somewhere there is an explanation and a history). Why 1903 I don't know--the only historical event I happened to come across when poking around in Google was the invention of the teabag. I have encountered a few of these files every now and again, and for unknown reasons files on my iDisk when it is mounted were showing that the other day, no one seems to know why (and it really bugged some people it also happened to). It used to happen when the little motherboard battery died, files created would get the default date, these days most people keep their clock set to get the time from the Apple server, so it seems not to happen much. In your case I would guess that the imported files were just lacking a readable creation date from XP, so the Finder assigned them the Mac default, and in the Terminal you are seeing the UNIX default. There are various ways to add a valid creation date, if you are interested.
Francine

Francine
Schwieder

Reply

Answer 10

netnothing Author

Level 1

76 points

Jun 20, 2008 2:17 PM in response to Francine Schwieder

I see this 1903 date when I mount my iDisk in Finder as well.

If I create a file on my system, the Created Date is correct.

If I upload it to iDisk, the date goes to 1903 on iDisk.
Bringing it back to my Mac, the created date stays 1903.

-Kevin

Reply

Answer 11

glsmith

Level 3

875 points

Jun 20, 2008 2:33 PM in response to netnothing

I'm not entirely sure where the Finder gets those timestamps. The Finder code is likely utilizing some number of abstracted API's, but at the end of the day it likely gets its information from a "stat" system call (the same thing that the "stat" command line utility I had you run earlier uses).

The HFS metadata probably is stored in the file somewhere. A file is just some number of data structures sitting on disk, usually referenced by the inode. It's likely the the filesystem developers coded it such that this metadata hangs off the inode in some fashion. I'm not a filesystem developer or even a developer, so I only have a vague understanding of how this could work. Maybe some filesystem-minded person will read this and set me straight 🙂

What has been made clear in this thread is that there definitely seems to be some inconsistencies with how the various timestamps are stored in the inode itself, versus where the metadata is kept.

Reply

Answer 12

netnothing Author

Level 1

76 points

Jun 20, 2008 3:29 PM in response to Francine Schwieder

Francine Schwieder wrote:

There are various ways to add a valid creation date, if you are interested.

Yeah, I figured doing a *cp -Rp* to another disk would at least set everything to the last modified date.

-Kevin

Reply

Answer 13

Jul 23, 2008 4:20 AM in response to Francine Schwieder

Hi Francine

How would you add valid file dates?

I current have pretty much an entire drive that says the files were created in 1978 and last modified in 2016. Neither of those are right.

Thanks

-h.

Reply

Answer 14

Jul 23, 2008 10:20 AM in response to hannes du plessis

I would use Super Get Info from Barebones Software to change created and/or modified dates on files, because I own a copy of it. However, it does not do batch processing so would not really help on fixing the contents of an entire drive. Another commercial tool, which was just updated for Leopard, is "A Better Finder Attributes" which is here:

http://www.publicspace.net/ABetterFinderAttributes/index.html

It looks like you could create a droplet with the dates you wished, then drop files/folders in batches onto the droplets.

I believe FileBuddy does much the same sort of thing:

http://www.skytag.com/filebuddy/

However, it has not been updated for Leopard. Whether it would work anyway, I don't know.
Francine

Francine
Schwieder

Reply

Answer 15

glsmith

Level 3

875 points

Jul 23, 2008 3:41 PM in response to glsmith

I believe there is a pretty serious problem at some level of the Cocoa API that is manipulating timestamps. I'll be filing a bug with Apple on this.

Just to follow up on this. I did file that bug, and did get a response back from Apple. Because of the way Vi (the editor I used in my tests) saves file, this outcome of my tests were expected. Vi first saves to a temporary location, then copies the temp file to the target location, then deletes the temp file. This causes all timestamps to be the same, since every time the file is saved it's seen as new...

Reply