Author pitrou
Recipients akuchling, ezio.melotti, pitrou, r.david.murray
Date 2009-11-01.14:50:23
SpamBayes Score 0.00110249
Marked as misclassified No
Message-id <1257087026.3.0.447601386449.issue6896@psf.upfronthosting.co.za>
In-reply-to
Content
The explanation seems to be that some systems (including RDM's buildbot)
have slightly bizarre mtime behaviour:

$ date && python -c 'import os; os.link("setup.py", "t/c")' && stat t &&
date
Sun Nov  1 09:49:04 EST 2009
  File: `t'
  Size: 144       	Blocks: 0          IO Block: 4096   directory
Device: 811h/2065d	Inode: 223152      Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1001/  pitrou)   Gid: ( 1005/  pitrou)
Access: 2009-11-01 09:10:11.000000000 -0500
Modify: 2009-11-01 09:49:03.000000000 -0500
Change: 2009-11-01 09:49:03.000000000 -0500
Sun Nov  1 09:49:04 EST 2009


As you see, the mtime of the directory is set a full one second before
the date at which its contents are modified.
I guess the only safe solution is to explicitly flush the internal cache
when we do any modifications.
History
Date User Action Args
2009-11-01 14:50:26pitrousetrecipients: + pitrou, akuchling, ezio.melotti, r.david.murray
2009-11-01 14:50:26pitrousetmessageid: <1257087026.3.0.447601386449.issue6896@psf.upfronthosting.co.za>
2009-11-01 14:50:24pitroulinkissue6896 messages
2009-11-01 14:50:23pitroucreate