John S. Gruber 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 wrote:
>
> Éric Araujo added the comment:
>
> Can you tes
John S. Gruber added the comment:
As Éric suggested I opened issue 11993 a couple of days ago.
--
___
Python tracker
<http://bugs.python.org/issue11933>
___
___
John S. Gruber 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 this. Please see msg 134634
New submission from John S. Gruber :
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 modification times, bu
John S. Gruber 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) (1303933305.5
John S. Gruber 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 releases and the old
John S. Gruber 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. Since this was done
John S. Gruber 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 file timestamps
New submission from John S. Gruber :
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:9211a5d7d0b4
wh
