What I learned today: You can’t tell how old a file is in Linux
Tuesday, 3 April 2012
I’m certain that there are all kinds of filesystems in the Linux world that support file creation dates, but the plain fact of the matter is if you perform a vanilla Ubuntu installation, your files will remain ageless.
Why should I care? In a word, Photographs. I keep everything I own on network attached storage devices that are formatted with popular Linux or Unix file systems that lack this information. When I move files between my Mac and one of these devices, the file creation time just doesn’t survive the trip.
I like to have the file creation timestamp match the EXIF time that the photo was taken—normally not a problem since the camera sets the EXIF time and file creation time at the same moment. Keeping the creation timestamp in sync with the EXIF timestamp makes it a snap to sort image files by chronological order.
In cases where the times are off, I use a handy-dandy tool called A Better Finder Attributes to copy the EXIF time to the file creation time.
On Mac OS X, you can easily view the file creation time as well as the file modification time, by adding the appropriate column to the Finder window:
So my assumption has always been that every file always has these two attributes, creation date and modified date, and that this data simply goes along for the ride whenever files are copied anywhere. Clearly that is a naive and simplistic view, and a moment’s thought made me realize that this information is metadata, not stored within the file, so it wouldn’t make sense for these timestamps to survive something as simple as traveling as an attachment to an email.
I was happily copying files between my local machine and a server using Forklift, and I was puzzled by the appearance of many “created date” values from 1969. Had the timestamp been 1970, I would have immediately figured that it was a Unix issue (the beginning of the Epoch), but the Year of Apollo 11 threw me off.
A quote from one of those pages:
Unix/Linux does not store file creation date and time as it stores modification/access/change date and time.
Here’s another quote:
Only FreeBSD and the UFS2 filesystem support file creation times (that they call “birth time”).
Is it a problem for me? Not really. But it’s nice to understand limitations like this when you are messing around with multiple machines in your workflow.
The practical impact of this is that I now have to copy the EXIF timestamps to the creation date and then copy the creation date to the modified date. I do this with two droplets I created with A Better Finder Attributes. Maybe the ABFA developer will tweak the tool a little bit to allow copying EXIF to created and modified in one operation. It can’t hurt to ask.
Oh, and why do I end up with the out-of-sync dates in the first place? Blame it on Aperture. After I edit photos and add captions and all kinds of nice stuff, I export the finished versions. The export operation does not provide a keep the original timestamps option—Aperture simply creates new files for you with fresh new timestamps. I somehow doubt Apple will listen to my opinions on this front, so I will deal with the timestamps myself.