[issue11933] newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat

2011-06-09 Thread John S. Gruber
John S. Gruber johnsgru...@gmail.com added the comment: The patch worked--it eliminated the redundant copy caused by this issue. Thank you very much, Éric. On Fri, Jun 3, 2011 at 12:39 PM, Éric Araujo rep...@bugs.python.org wrote: Éric Araujo mer...@netwok.org added the comment: Can you

[issue11933] newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat[ST_MTIME]

2011-05-06 Thread John S. Gruber
John S. Gruber johnsgru...@gmail.com added the comment: As Éric suggested I opened issue 11993 a couple of days ago. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11933

[issue11993] Is it desired to distinguish new files from old with sub-second resolution?

2011-05-03 Thread John S. Gruber
New submission from John S. Gruber johnsgru...@gmail.com: This report is meant to prompt discussion, if desired, on the advisability of distinguishing new files from old using subsecond data. (It isn't clear to me that it is important to do this.) Some file systems keep sub-second

[issue11993] Is it desired to distinguish new files from old with sub-second resolution?

2011-05-03 Thread John S. Gruber
John S. Gruber johnsgru...@gmail.com added the comment: Thanks for writing so quickly. This topic arose as part of issue 11933 (similar number). Éric Araujo asked that I bring this up in either mail to the fellowship of the packaging or as a separate bug report, so I chose to file

[issue11933] newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat[ST_MTIME]

2011-04-27 Thread John S. Gruber
John S. Gruber johnsgru...@gmail.com added the comment: Thanks for considering my report so quickly. Attached is a simple test to reproduce the bug, as you suggested. Please note that I am not suggesting the code base use stat.st_mtime. Running the attached with ext4, which keeps sub-second

[issue11933] newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat[ST_MTIME]

2011-04-27 Thread John S. Gruber
John S. Gruber johnsgru...@gmail.com added the comment: The original bug report is at: https://bugs.launchpad.net/ubuntu/+source/python-distutils-extra/+bug/770566 As you can see it had to do with a symbolic link created by distutils-extra before distutils was called upon to copy anything

[issue11933] newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat[ST_MTIME]

2011-04-27 Thread John S. Gruber
John S. Gruber johnsgru...@gmail.com added the comment: I can understand what you are saying about side effects. I was trying to suggest that the move to stat.st_mtime in dep_util.py in the hg commit I mentioned be reverted back to use stat[ST_MTIME], thereby matching the other python

[issue11933] newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat[ST_MTIME]

2011-04-27 Thread John S. Gruber
John S. Gruber johnsgru...@gmail.com added the comment: As I thought about it, I suppose I should demonstrate the problem with stat.st_mtime. Here's an example and its output on an ext4 file system: gruber@gruber-Satellite-L355D:~$ ./mtime.py (1303933305.5525582, 1303933305.5525582

[issue11933] newer() function in dep_util.py mixes up new vs. old files due stat.st_mtime vs stat[ST_MTIME]

2011-04-26 Thread John S. Gruber
New submission from John S. Gruber johnsgru...@gmail.com: In researching a bug I was surprised that a newly created file was being replaced when being processed a second time (it shouldn't have been processed a second time). I tracked the surprise to diff Lib/distutils/dep_util.py @ 57642