3

I'm trying to determine how file access times are maintained by default in Mac OS X, as I'm trying to diagnose some odd behaviour I'm seeing in a new MBP Unibody (running Snow Leopard, 10.6.2):

The symptoms (drilling down to the specific behaviour that seems to be causing the issue):

  • mutt is unable to switch to mailboxes which have recently received new mail
  • mail is delivered by procmail, which updates the mtime of the mbox folder it is updating, but does not alter the atime (this is how new mail detection works: by comparing atime to mtime)
  • however, both the mtime and atime of the mbox file is getting updated

Through testing, it does not appear that atimes can be set separately in the filesystem:

: [ether@tequila ~]$; touch test
: [ether@tequila ~]$; touch -m -t 200801010000 test2
: [ether@tequila ~]$; touch -a -t 200801010000 test3
: [ether@tequila ~]$; ls -l test*
-rw-------  1 ether  staff  0 Dec 30 11:42 test
-rw-------  1 ether  staff  0 Jan  1  2008 test2
-rw-------  1 ether  staff  0 Dec 30 11:43 test3
: [ether@tequila ~]$; ls -lu test*
-rw-------  1 ether  staff  0 Dec 30 11:42 test
-rw-------  1 ether  staff  0 Dec 30 11:43 test2
-rw-------  1 ether  staff  0 Dec 30 11:43 test3

The test2 file is created with an old mtime, and the atime is set to now (as it is a new file), which is correct. However, test3 is created with an old atime, but is not set properly on the file. To be sure this is not just behaviour seen with new files, let's modify an old file:

: [ether@tequila ~]$; touch -a -t 200801010000 test
: [ether@tequila ~]$; ls -l test
-rw-------  1 ether  staff  0 Dec 30 11:42 test
: [ether@tequila ~]$; ls -lu test
-rw-------  1 ether  staff  0 Dec 30 11:45 test

So it would seem that atimes cannot be set explicitly (it is always reset to "now" when either mtime or atime modifications are submitted).

Is this something inherent to the filesystem itself, is it something that can be changed, or am I totally crazy and looking in the wrong place?

PS. the output of mount is:

: [ether@tequila ~]$; mount
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)

...and Disk Utility says that the drive is of type "Mac OS Extended (Journaled)".

2
  • After running the touch command, what does echo $? report?
    – user1931
    Dec 30, 2009 at 20:24
  • All commands report $?=0.
    – Ether
    Dec 30, 2009 at 20:41

1 Answer 1

8

From man touch (on snow leopard):

Change the modification time of the file.  The access time of the
file is not changed unless the -a flag is also specified.

More importantly, it works fine for me:

betelgeuse:tmp james$ touch test
betelgeuse:tmp james$ touch -m -t 200801010000 test2
betelgeuse:tmp james$ touch -a -t 200801010000 test3
betelgeuse:tmp james$ ls -lu test*
-rw-r--r--  1 james  wheel  0 31 Dec 07:41 test
-rw-r--r--  1 james  wheel  0 31 Dec 07:41 test2
-rw-r--r--  1 james  wheel  0  1 Jan  2008 test3
betelgeuse:tmp james$ ls -l test*
-rw-r--r--  1 james  wheel  0 31 Dec 07:41 test
-rw-r--r--  1 james  wheel  0  1 Jan  2008 test2
-rw-r--r--  1 james  wheel  0 31 Dec 07:41 test3
betelgeuse:tmp james$ 

On the other hand, when I try the same thing in ~ I get the same results as you:

betelgeuse:~ james$ touch test
betelgeuse:~ james$ touch -m -t 200801010000 test2
betelgeuse:~ james$ touch -a -t 200801010000 test3
betelgeuse:~ james$ ls -lu test*
-rw-r--r--  1 james  staff  0 31 Dec 07:42 test
-rw-r--r--  1 james  staff  0 31 Dec 07:42 test2
-rw-r--r--  1 james  staff  0 31 Dec 07:42 test3

The difference? Spotlight doesn't index /tmp, but it does index ~. I'm pretty sure that what you're seeing here is spotlight reading the file to index it after you change the atime - which then sets the atime back to now.

Solution is easy: just add the dirs you don't want indexed to Spotlight's list of folders that shouldn't be indexed.

Just to confirm that this was the case, I made a new dir called "nospotlight" and told Spotlight not to index it.

betelgeuse:nospotlight james$ ls -l *
-rw-r--r--  1 james  staff  0 31 Dec 07:47 test
-rw-r--r--  1 james  staff  0  1 Jan  2008 test2
-rw-r--r--  1 james  staff  0 31 Dec 07:47 test3
betelgeuse:nospotlight james$ ls -lu *
-rw-r--r--  1 james  staff  0 31 Dec 07:47 test
-rw-r--r--  1 james  staff  0 31 Dec 07:47 test2
-rw-r--r--  1 james  staff  0  1 Jan  2008 test3

Give Spotlight permission to index it, and mere seconds later:

betelgeuse:nospotlight james$ ls -lu *
-rw-r--r--  1 james  staff  0 31 Dec 07:48 test
-rw-r--r--  1 james  staff  0 31 Dec 07:48 test2
-rw-r--r--  1 james  staff  0 31 Dec 07:48 test3

and once again, modifying the mtime results in an updated atime.

It's definitely Spotlight.

2
  • Confirmed! atime is left alone if mail/ is added to Spotlight's "Privacy" list, and mutt/procmail work as expected. I'm dismayed that Spotlight doesn't know well enough to fix the atime -- otherwise it rather defeats the purpose of having an atime to begin with. :(
    – Ether
    Dec 30, 2009 at 20:55
  • Well, it did alert you to the fact that something was snooping through your mutt folders :p Dec 30, 2009 at 21:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .