On Sun,  1 May 2011 00:15:11 +0200, R. David Murray <report@bugs.python.org> wrote:
> So actually fixing this is a bit more complicated.

I like Pear OS X!
I've just tried around a bit with the other of the Pear OS
filesystems (claims to "support" two fsys: HFS+ and HFS, case
sensitive, the latter may indeed be UFS).
The following (reduced) HFS, case sensitive (UFS?) session brings
out the problem:

Access: Mon May  2 20:49:51 2011
Modify: Mon May  2 20:49:30 2011
Change: Mon May  2 20:49:50 2011
>>> os.utime('org.python', (t-3,t))
Access: Mon May  2 20:50:19 2011
Modify: Mon May  2 20:49:30 2011
Change: Mon May  2 20:50:17 2011
>>> os.utime('org.python', (t-3,t))
Access: Mon May  2 20:51:12 2011
Modify: Mon May  2 20:49:30 2011
Change: Mon May  2 20:51:11 2011

Thus the HFS, case sensitive (UFS?) implementation of f?utimes(2)
updates ctime.
It also updates atime to one+ second *after* ctime.
Well, i'm lucky it doesn't update mtime too, because ,man 2 stat`
*does* document it!!!
So, to get around yet another Pear OS X bug (unless it's really
UFS which, then, maybe has been taken as-is from FreeBSD??) i've
changed the S-Postman to do

    os.utime(self._path, (currtime, currtime+2.42))

instead, i.e. i'm using a future date.  B-/
I don't think this approach can be used by Python, however.
Non-believers:

posix.stat_result(...st_atime=1304363003, st_mtime=1304363005, st_ctime=1304363005)
>>> print(os.stat('org.python'))
posix.stat_result(...st_atime=1304363011, st_mtime=1304363005, st_ctime=1304363005)

So in fact it seems as if asynchronously the atime is updated once
again by someone, don't know who, because actually this system is
non-journaled.  Pear OS X is a Microkernel, AFAIK.