Trent Nelson added the comment:
Thanks for the feedback Larry; yeah that patch definitely wasn't intended to be
"production quality" -- more of a proof of concept. I agree with your points,
they'll be factored into the next patch.
However, I'm absolutely baffled by the Solaris 10 failure. The more I looked
into it, the weirder it got. The issue is always the same:
self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime"))
AssertionError: 1347752941.275297 != 1347752941.275296
That is, test_utime() always results in a st1.st_mtime that is "off-by-1" from
st0.st_mtime. The precision is well within the nanasecond resolution offered
by utimensat, so it doesn't appear to be the same issue experienced by other
platforms.
I'll have to break into the debugger again and see what's going on.
Side note: I noticed this comment/code just above _test_utime():
def test_utime_dir(self):
delta = 1000000
st = os.stat(support.TESTFN)
# round to int, because some systems may support sub-second
# time stamps in stat, but not in utime.
os.utime(support.TESTFN, (st.st_atime, int(st.st_mtime-delta)))
st2 = os.stat(support.TESTFN)
self.assertEqual(st2.st_mtime, int(st.st_mtime-delta))
That... seems to (albeit vaguely) describe what's going on here with Solaris
10. I also noticed support.TESTFN is actually a directory in this test case.
Again, I'm not sure how that fits in with test_utime_dir() versus a second
invocation of _test_utime(support.TESTFN) from test_utime().
test_utime_dir() is ultra-lax, test_utime() is ultra-strict, I'm not sure which
one should be updated to match the other.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15745>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
