Geek Answers Handbook

Modified / created / available time mismatch on mac

I am having problems using os.utime to correctly set the modification time on Mac (Mac OS X 10.6.2, starting Python 2.6.1 from /usr/bin/python ). This does not match the touch utility and does not match the properties displayed in the Get Info window Finder.

Consider the following sequence of commands. “Created” and “changed” clear-text times refer to attributes displayed in the Get Information window of a search appliance. Recall that os.utime accepts the arguments (filename, (atime, mtime)) .

 >>> import os >>> open('tempfile','w').close()

'created' and 'modified' are the current time.

 >>> os.utime('tempfile', (1000000000, 1500000000) )

'created' is the current time, 'modified' is July 13, 2017.

 >>> os.utime('tempfile', (1000000000, 1000000000) )

'created' and 'modified' is September 8, 2001.

 >>> os.path.getmtime('tempfile') 1000000000.0 >>> os.path.getctime('tempfile') 1269021939.0 >>> os.path.getatime('tempfile') 1269021951.0

... but os.path.get?time and os.stat do not reflect it.

 >>> os.utime('tempfile', (1500000000, 1000000000) )

'created' and 'modified' are still September 8, 2001.

 >>> os.utime('tempfile', (1500000000, 1500000000) )

'created' - September 8, 2001, 'modified' - July 13, 2017.

I am not sure if this is a Python problem or a problem with a Mac file. When I exit the Python shell and run

 touch -a -t 200011221234 tempfile

Neither the change nor the time of creation changes as expected. Then i ran

 touch -m -t 200011221234 tempfile

and both “created” and “changed” times are changed.

Does anyone know what is going on? How to change changes and creation time on Mac? (Yes, I know that on Unixy systems there is no "creation time".)

The result of running the Chris Johnsen script:

 seth@local :~$ /usr/bin/python timetest.py tempfile 5 initial: (1269631281.0, 1269631281.0, 1269631281.0, 1269631281, 1269631281, 1269631281) test: (1000000000, 1000000000) (1000000000.0, 1000000000.0, 1269631281.0, 1000000000, 1000000000, 1269631281) (1269631281.0, 1000000000.0, 1269631281.0, 1269631281, 1000000000, 1269631281) test: (1000000000, 1500000000) (1000000000.0, 1500000000.0, 1269631286.0, 1000000000, 1500000000, 1269631286) (1269631286.0, 1500000000.0, 1269631286.0, 1269631286, 1500000000, 1269631286) test: (1500000000, 1000000000) (1500000000.0, 1000000000.0, 1269631291.0, 1500000000, 1000000000, 1269631291) (1269631291.0, 1000000000.0, 1269631291.0, 1269631291, 1000000000, 1269631291) test: (1500000000, 1500000000) (1500000000.0, 1500000000.0, 1269631296.0, 1500000000, 1500000000, 1269631296) (1269631296.0, 1500000000.0, 1269631296.0, 1269631296, 1500000000, 1269631296)

At the end of the exercise, the “created” date is visible as 9/8/01 in the search object, and the “modified” date is 7/13/17. (The access date is apparently in the spotlight, as you suggest, and, as I read, roughly “now.”) Created and modified dates visible in the search device still make no sense.

+6
python touch stat macos
source share
2 answers

POSIX atime, mtime, ctime

This may help if you included the full script and its actual and expected outputs instead of REPL fragments.

 import sys, os, stat, time def get_times(p): s = os.stat(p) return ( os.path.getatime(p), os.path.getmtime(p), os.path.getctime(p), s[stat.ST_ATIME], s[stat.ST_MTIME], s[stat.ST_CTIME], ) def main(p, delay=1): delay = float(delay) (a,b) = (1000000000, 1500000000) open(p,'w').close() print 'initial:' print get_times(p) for t in [ (a,a), (a,b), (b,a), (b,b) ]: print print 'test:', t os.utime(p,t) print get_times(p) time.sleep(delay) print get_times(p) main(*sys.argv[1:])

I get this on my 10.4 system with cd "$HOME" && python test.py tempfile 5 (system default Python 2.3.6 and MacPorts Python 2.6.4 both give the same result (of course, excluding start times and ctime)):

 % python /tmp/test.py tempfile 5 initial: (1000000000.0, 1000000000.0, 1269629881.0, 1000000000, 1000000000, 1269629881) test: (1000000000, 1000000000) (1000000000.0, 1000000000.0, 1269629881.0, 1000000000, 1000000000, 1269629881) (1000000000.0, 1000000000.0, 1269629881.0, 1000000000, 1000000000, 1269629881) test: (1000000000, 1500000000) (1000000000.0, 1500000000.0, 1269629886.0, 1000000000, 1500000000, 1269629886) (1000000000.0, 1500000000.0, 1269629886.0, 1000000000, 1500000000, 1269629886) test: (1500000000, 1000000000) (1500000000.0, 1000000000.0, 1269629891.0, 1500000000, 1000000000, 1269629891) (1500000000.0, 1000000000.0, 1269629891.0, 1500000000, 1000000000, 1269629891) test: (1500000000, 1500000000) (1500000000.0, 1500000000.0, 1269629896.0, 1500000000, 1500000000, 1269629896) (1500000000.0, 1500000000.0, 1269629896.0, 1500000000, 1500000000, 1269629896)

That seems reasonable. I wonder what you get.

I heard that Spotlight can sometimes aggressively reset atime due to reindexing modified files. I would not expect it to reindex the file that utime () / utimes () just underwent, but I assume that this is possible. To fix Spotlight as a possible complication, use a file in a place that is not indexed by Spotlight (for example, / tmp / testfile).

Date Created in Finder

(shown as "Created:" in the "Get Information" Finder window)

If you have the developer tools installed, you can use /Developer/Tools/GetFileInfo to see the HFS creation file. I added the following lines after each line of print get_times(p) :

 sys.stdout.flush() os.system('/Developer/Tools/GetFileInfo ' + p)

I also changed the iteration according to your initial description ( [ (a,b), (a,a), (b,a), (b,b) ] ).

The result now looks like this:

 % rm /tmp/tempfile; python /tmp/test.py /tmp/tempfile 1 initial: (1269636574.0, 1269636574.0, 1269636574.0, 1269636574, 1269636574, 1269636574) file: "/private/tmp/tempfile" type: "" creator: "" attributes: avbstclinmedz created: 03/26/2010 15:49:34 modified: 03/26/2010 15:49:34 test: (1000000000, 1500000000) (1000000000.0, 1500000000.0, 1269636574.0, 1000000000, 1500000000, 1269636574) file: "/private/tmp/tempfile" type: "" creator: "" attributes: avbstclinmedz created: 03/26/2010 15:49:34 modified: 07/13/2017 21:40:00 (1000000000.0, 1500000000.0, 1269636574.0, 1000000000, 1500000000, 1269636574) file: "/private/tmp/tempfile" type: "" creator: "" attributes: avbstclinmedz created: 03/26/2010 15:49:34 modified: 07/13/2017 21:40:00 test: (1000000000, 1000000000) (1000000000.0, 1000000000.0, 1269636576.0, 1000000000, 1000000000, 1269636576) file: "/private/tmp/tempfile" type: "" creator: "" attributes: avbstclinmedz created: 09/08/2001 20:46:40 modified: 09/08/2001 20:46:40 (1000000000.0, 1000000000.0, 1269636576.0, 1000000000, 1000000000, 1269636576) file: "/private/tmp/tempfile" type: "" creator: "" attributes: avbstclinmedz created: 09/08/2001 20:46:40 modified: 09/08/2001 20:46:40 test: (1500000000, 1000000000) (1500000000.0, 1000000000.0, 1269636577.0, 1500000000, 1000000000, 1269636577) file: "/private/tmp/tempfile" type: "" creator: "" attributes: avbstclinmedz created: 09/08/2001 20:46:40 modified: 09/08/2001 20:46:40 (1500000000.0, 1000000000.0, 1269636577.0, 1500000000, 1000000000, 1269636577) file: "/private/tmp/tempfile" type: "" creator: "" attributes: avbstclinmedz created: 09/08/2001 20:46:40 modified: 09/08/2001 20:46:40 test: (1500000000, 1500000000) (1500000000.0, 1500000000.0, 1269636578.0, 1500000000, 1500000000, 1269636578) file: "/private/tmp/tempfile" type: "" creator: "" attributes: avbstclinmedz created: 09/08/2001 20:46:40 modified: 07/13/2017 21:40:00 (1500000000.0, 1500000000.0, 1269636578.0, 1500000000, 1500000000, 1269636578) file: "/private/tmp/tempfile" type: "" creator: "" attributes: avbstclinmedz created: 09/08/2001 20:46:40 modified: 07/13/2017 21:40:00

This is similar to your observations from the Get Info window in Finder. My interpretation (confirmed by other experiments) is that the HFS creation file is updated using utime, but it only ever goes backward (never forward). If you want to upgrade the HFS creationDate to a newer value, you probably have to use the Mac API for this.

One more note: you may need to switch windows a bit to refresh the Get Info window. On my system, its display is not updated automatically unless I switch the windows to either the Get Info window or the Product Information window.

+2
source share

Mac OS supports additional attributes that are not mapped to posix.

  • createDate
  • contentModDate
  • attributeModDate
  • accessDate
  • backupDate

You had access to them through the old macfs module, which has long been deprecated in favor of the Carbon module, which is largely undocumented, and also now deprecated. I think Carbon.File and Carbon.Folder have what you need. (I don't stick with the Mac enough to find out what the current plan for these features is. Maybe Carbon is just getting pulled out of stdlib and it will continue on its own.)

Maybe a comment detailing what you're looking for will help instead of downvote

I'm not quite sure what other sequence you expect. Python uses the posix api, and Apple tools use the Apple api. Each seems internally consistent, but they may differ from each other.

  • attributeModDate is displayed in ctime.
  • createDate is what Finder displays for "created"
  • If you changed mtime to earlier than createDate, the Mac api file system will modify createDate to match; which prevents the inconsistency of apparent modification before creation. This applies to the only inconsistent behavior that I can collect from your example above.
0
source share

More articles:


All Articles