setting creation and modification date problem

I’m trying to set the creation and modification dates of a file. I’m using the “SetFile” unix executable to do this. Note that this exe file is only installed if you have the developer tools installed. The problem is that the file time that gets set is one hour less than the time I have chosen. Try this script and see for yourself. Any ideas how to solve this? I assume it has something to do with daylight savings time but I’m not sure how to fix it. I’m in the US Eastern Time Zone.

Note: this script creates a new file on the desktop using “touch” and then sets its dates. The actual creation and modification dates of the file are returned at the end of the script. You’ll see that the times are different from what I chose.

-- this will create the follwoing file on your desktop and set its creation and modification dates
set aFile to (path to desktop folder as text) & "test.txt" -- a dummy file to test with
set {creationDate, modificationDate} to {"10/03/2008 14:28:10", "07/23/2009 02:07:47"} -- some arbitrary dates

-- create the file, delete it if it exists
	do shell script "rm " & quoted form of POSIX path of aFile
end try
do shell script "touch " & quoted form of POSIX path of aFile

-- set creation and modification dates of a file
do shell script "/Developer/Tools/SetFile -d " & quoted form of creationDate & space & quoted form of POSIX path of aFile
do shell script "/Developer/Tools/SetFile -m " & quoted form of modificationDate & space & quoted form of POSIX path of aFile

-- check the new dates of the file
set cd to do shell script "/Developer/Tools/GetFileInfo " & quoted form of POSIX path of aFile & " | grep created | cut -c 10-"
set md to do shell script "/Developer/Tools/GetFileInfo " & quoted form of POSIX path of aFile & " | grep modified | cut -c 11-"
return {cd, md}

Hey Hank,

When I run the above script this is what is returned.

Hi Craig,

I get this returned…
{“10/03/2008 13:28:10”, “07/23/2009 01:07:47”}

I notice that by changing the month value that if it’s anything from 04 to 11 it is one hour less, the other months are created properly. That’s why I think it’s a daylight savings time thing. You must have some different DST factor.

You are probably right. Any ideas how you will fix it or account for it?

Weird… I changed my time zone in the Date & Time preference pane to Denver. I assume that’s what you are using. I still get the improper time with that setting… so I’m confused.

I think what is really weird is that no matter what your date/time settings are it should not effect a time you are specifically setting on a file. What you set should be what you get back. Something else seems to be going on here. I am searching the net to see if anyone has posted similar situation.

Out of curosity, what is the mod date if you open the file, make a change and close it?

Is it still an hour earlier?

No, the mod date is right… 3:09 PM here on the east coast.

Try this script and see what the results are.

Yes, that script works. The problem is it doesn’t do anything to the creation date. I want that ability. I use this when I’m backing up files with Chronosync. If the creation or mod dates are different a backed-up file is overwritten, so I use this when I don’t want a particular file to be overwritten when backing up.

True, but at least this narrows down the issue to the SetFile command and not something with your system or time settings.

Have you considered writing a foundation tool?

Well if nobody has any ideas, then I’ll have to try something more drastic… but I still have hope somebody has an idea how to work around this.

If you us -mt it changes both created and modified dates. You could then issue another command to change the modified to a different date.

So, as an example:

Unfortunately this doesn’t work right. It only impacts the creation date of a file if the mod date you are setting is before the current creation date. For example, using the text.txt file we created with a creation date of 10/03/2008. If you touch it with a date of 11/03/2008 as you suggest then the creation date stays as 10/03/2008. So touch doesn’t really change creation dates. Thanks for the suggestion though.

I am guessing you have already done this but if not… :slight_smile:

There could be better error checking and you could have the tool process all the files instead of passing them in one at at time but it appears to be working.

Excellent Craig. I didn’t realize there were NSFileCreationDate and NSFileModificationDate cocoa attributes for NSFileManager… so no I haven’t tried that. But i definitely will! Thanks. I’ll report back how it works when I get the chance to try your code… probably tomorrow.


It’s the same thing for me here.

My solution is to use the “SetFile” (May 2007 or older) instead of the “SetFile” (September 2007 or newer).

You can find it in the “Xcode Tools” on Tiger.

Or in the ( MacOSXUpdate, MacOSXUpdCombo ) package :
SetFile is in the the resources folder in a package like this (/Library/Receipts/MacOSXUpd10.4.10.pkg)

Hi Craig,

memory management alert! If you retain objects, you are responsible to release them.
This is not so important in a CLI, which will be terminated at once, but you should always consider memory management.
In this case you can omit all retain messages, they are not necessary

So true. I have been building FileMaker Pro databases and websites for the last few months and this is the first Objective-C code I have written in a while. How fast we forget the basics! :wink:

Most of the time I would rather retain and then release though, as Hank can testify, autorelease can bite you in the butt. If you retain it, you don’t have to worry whether it is going to be there when you want to use it.

In the same scope you don’t have to worry. The system will keep args alive during the whole method