Antoine Pitrou <pit...@free.fr> added the comment:
> Hmm. 411-61=350. Three seconds difference looks a little odd. But
> doesn't explain 60 vs 61 making the difference in the test.
>
> Can you change it back to 60 (or even less) and see what the values
> look like when the test fails?
Hmm, 60 doesn't fail anymore so I changed it to 1 (!) and here is the
result:
before: os.path.getmtime('cur') = 1301078411.882165
before: os.path.getmtime('new') = 1301078411.8801715
after: os.path.getmtime('cur') = 1301078410.802999
after: os.path.getmtime('new') = 1301078410.802999
self._box._last_read = 1301078410.787
time.time() = 1301078411.818
(it fails obviously)
> It is interesting (and possibly meaningful) that the last modified
> time 'before' appears to be in the future compared to time.time by
> 3-plus seconds. That would at least explain why the test fails
> without the patch.
Yep, although the drift is varying. Sometimes small, sometimes big. At
this point I think it's just caused by my setup (the fact that VM and
host aren't always synchronized - I once witnessed time advancing
quicker on the VM than on the host! -, and the fact that a network FS is
used).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9557>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
