Trent Nelson added the comment:
On Tue, Oct 16, 2012 at 10:46:34PM -0700, Trent Nelson wrote:
>
> 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've concluded that the problem on Solaris is actually unrelated
to the original failures on FreeBSD and NetBSD that this issue
was raised for (where os.stat() returns nanosecond resolution but
os.utime() only accepts microsecond).
I've raised a separate bug for this issue: #16287.
----------
title: Numerous utime ns tests fail on FreeBSD w/ ZFS -> Numerous utime ns
tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)
_______________________________________
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
