blog.sudosu.net » Python

File “Created Date” Under OS X — Harder Than You Think

schof — Sat, 11 Apr 2009 21:28:57 +0000

A client had an OS X server with tens of thousands of files in a directory tree, and wanted to move some of them based on their creation date. I put together a Python script that worked perfectly on my test system, but failed in production. (I put in a “–dryrun” option, so no harm was done.)

The modification date the script reported was correct, but the creation date the script reported was different from the creation date that doing “Get Info” in the OS X Finder reported. Hmm. Not good. I did some investigating.

Let’s look at a test file. The Finder reports the following creation and modification dates:
Created: Monday, April 10, 2006 17:04 Modified: Thursday, April 13, 2006 15:54

Python reports a different creation date and the same modification date:
>>> import os.path >>> import time >>> stamp = os.path.getctime('datetest.txt') >>> time.ctime(stamp) 'Fri Apr 10 15:51:10 2009' >>> stamp = os.path.getmtime('datetest.txt') >>> time.ctime(stamp) 'Thu Apr 13 15:54:43 2006'
Hmmm. What does “ls” in the Terminal report? The standard “ls -l” reports creation date. Adding “-T” makes it report the full date in all cases. And “-c” counter-intuitively means “display modification date.”
$ ls -lT datetest.txt -rwxr-xr-x@ 1 schof schof 2448091 Apr 13 15:54:43 2006 datetest.txt $ ls -lcT datetest.txt -rwxr-xr-x@ 1 schof schof 2448091 Apr 10 15:51:10 2009 datetest.txt
The plot thickens. The modification date matches the Finder and Python, but both Python and ls are reporting an incorrect (according to the Finder) creation date.

Quite a bit of Googling showed me the “mdls” tool — or “metadata ls.” Very useful. This shows the complete set of metadata for a file. Including the OS X creation date. Actually, two creation dates, one for the file, and one for the file content. (I’m not sure what circumstances would make those creation dates differ. The documentation I’ve been able to find has been unclear and contradictory.)

$ mdls datetest.txt kMDItemContentCreationDate = 2006-04-10 17:04:34 -0700 kMDItemContentModificationDate = 2006-04-13 15:54:43 -0700 ... kMDItemFSContentChangeDate = 2006-04-13 15:54:43 -0700 kMDItemFSCreationDate = 2006-04-10 17:04:34 -0700 ... kMDItemLastUsedDate = 2009-04-11 11:48:03 -0700 kMDItemUsedDates = ( 2009-04-11 00:00:00 -0700 )

Now that we’ve got all that information, what does it tell us? The Unix/Linux standard for “creation date” is to show you the date on which a particular file was created. If you copy file “a” to file “b,” those are two different files, and the “creation date” for file “b” will be the date you made the copy.

OS X metadata travels with the file, so if you copy file “a” to file “b” using ditto on the command-line or using the Finder, the Unix creation date will be the date the copy was done, but the OS X creation date of file “b” will be the same as file “a.”

There’s good arguments for handling “creation date” the Unix way, and there are good arguments for doing “creation date” the OS X way, but mixing them as OS X does is kind of frustrating.

I’ve written a quick-and-dirty Python example script that reports the Unix creation date and the OS X creation date for any particular file. Since it’s released under the open-source MIT license, feel free to use it in your own programs. You can download it here: http://www.sudosu.net/getcreationdate.safe.

Working on the spec for SPBS

schof — Fri, 08 Feb 2008 18:23:03 +0000

I’ve been working on the spec for SPBS — it’s slow going, as my real job has been taking most of my focus. But I realized that in designing the templating system for the blog, I’m actually designing a domain-specific mini-language. I think I’m going to reread that chapter of The Art of Unix Programming.

But in general, I’m finding SPBS both challenging and a hell of a lot of fun. It’s turning into a bigger project than I expected — or perhaps, a better way of saying it is that SPBS is slowly revealing its complexity to me. I could get this done a lot fast by adapting pyBloxsom. But where’s the fun in that? {grin}

Announcing The Launch Of SPBS — the Simplest Possible Blogging System

schof — Thu, 07 Feb 2008 07:24:27 +0000

And by “Launch,” I mean “I’m starting to write it.” There’s a long way between that and a completed program. But you can check my progress at SPBS’ Google Code site: http://code.google.com/p/spbs/

I’ve written an introduction to SPBS, and the reasons I’m writing it here, at http://code.google.com/p/spbs/wiki/SPBSIntroduction

Google FTW: Fixing Arrow Problems in OS X Python

schof — Fri, 16 Nov 2007 00:38:35 +0000

I lived with it for ages. I tried to fix it on my own, by selecting different emulation types. Finally I Googled for it. And pretty much instantly found the answer:

python `python -c “import pimp; print pimp.__file__”` -i readline

Moral? If at first you don’t succeed, Google. If Google fails, try, try again.

Update: And to make forward-delete work, try this.

My Workflow: TextMate, Subversion, and Python

schof — Mon, 02 Apr 2007 01:33:49 +0000

I’m focusing in on some very important parts of my workflow. Version control is Subversion. I’m most of the way through the book on it.

Text editing is TextMate. I was trying to use vim, because it’s one editor I can use both on my OS X desktop and SSH’d across the network to linux boxes. I will continue to use vim remotely — though I may look at emacs as well. But for local editing, it’s TextMate for sure. Its functionality when dealing with large source code files and trees with many different files is impressive — I can see myself working significantly more efficiently with TextMate.

I’m used to working on the command-line with Subversion, but TextMate integrates with it, so I can commit changes by hotkey, etc.

And Python is rapidly becoming my system administration language of choice. All of this seems to fit together really well.