Martin Panter added the comment:
Okay, now at Issue 24675
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Changes by Martin Panter vadmium...@gmail.com:
Removed file: http://bugs.python.org/file39955/stat-times-deprecated.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
Martin Panter added the comment:
This patch defeats the warnings
--
status: closed - open
Added file: http://bugs.python.org/file39955/stat-times-deprecated.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
Martin Panter added the comment:
The commit causes test_os to emit DeprecationWarning warnings, which it didn’t
before:
[vadmium@localhost cpython]$ hg update 4335d898be59
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
[vadmium@localhost cpython]$ ./python -bWdefault -m
STINNER Victor added the comment:
The issue looks to be fixed on Python 3.4, 3.5 and 3.6. I checked quickly
buildbots. I close the issue.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
I applied the fix to Python 3.4 and 3.5 too.
Python 2.7 doesn't look to be affected by the issue, I don't see any test
copying the timestamp of a file to another, nor test on timestamp using
nanosecond resolution.
--
versions: -Python 2.7
Roundup Robot added the comment:
New changeset 50ec3fb126dd by Victor Stinner in branch '3.4':
Issue #15745: Rewrite os.utime() tests in test_os
https://hg.python.org/cpython/rev/50ec3fb126dd
New changeset 744c96cd57da by Victor Stinner in branch '3.5':
(Merge 3.4) Issue #15745: Rewrite
Roundup Robot added the comment:
New changeset 4335d898be59 by Victor Stinner in branch 'default':
Issue #15745: Rewrite os.utime() tests in test_os
https://hg.python.org/cpython/rev/4335d898be59
--
nosy: +python-dev
___
Python tracker
STINNER Victor added the comment:
I pushed test_utime.patch with minor updates:
* _test_utime_current() now also checks if the FS supports subsecond
* use a delta of 20 ms in _test_utime_current(), instead of 10 ms, for Windows
I will wait for FreeBSD and Solaris buildbots to see if my changes
koobs added the comment:
Additionally on koobs-freebsd9, in my home directory (which is on ZFS)
The buildbot home directories are on UFS
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
koobs added the comment:
Larry: The same two hosts that the FreeBSD Python buildslaves run on :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
R. David Murray added the comment:
Note that the shorter patch means that the test is not actually testing what
the comments say it is testing, so either the comments should admit we are
checking that the result is something close to what we set, or the longer fix
should be used so as to
koobs added the comment:
I have tested both patches (test_os by trent) and almostequaltime by harrison
on the default branch, and *both* result in test_os passing.
They also resolve the test_utime failure reported in bug 24175 and very likely
16287 (born from this issue)
--
versions:
koobs added the comment:
Hmm, that was supposed to be: issue 24175 and very likely issue 16287
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
STINNER Victor added the comment:
The resolution of os.utime()+os.stat() depends on two things:
- resolution of the timestamp on the filesystem used to run test_os (where
TESTFN is written)
- resolution of the C internal function used by os.utime()
os.utime() can have a resolution of 1 ns
STINNER Victor added the comment:
test_utime_ns.patch: rewrite _test_utime_ns(). It now uses constant timestamps
for atime and mtime with a resolution of 1 us.
The test will fail if the internal function of os.utime() has a resolution of 1
sec (utime() with time_t) of if the resolution of
STINNER Victor added the comment:
almostequaltime.diff is wrong: it allows a different of 10 seconds, whereas the
issue is a difference of less than 1000 nanoseconds.
test_os.patch looks more correct, but I didn't review the patch.
--
___
Python
STINNER Victor added the comment:
test_utime.patch: a much larger patch which rewrites all unit tests on
os.utime().
Changes:
* Use a fixed timestamp instead of copying timestamps from an existing file. If
the timestamp of the original file can have a resolution of 1 nanosecond,
os.utime()
koobs added the comment:
Can a test be made to show a message (similar to a skipIf reason=) mentioning
that a reduced precision is being used for certain tests?
It would be nice not to have to remember this issue as platform support changes
(reads: improves) over time.
Not withstanding, it's
Harrison Grundy added the comment:
The attached patch just explicitly cuts precision down for the test. It may be
worth adding code to set delta to the expected level of precision for a given
platform, rather than just universally saying Microseconds are okay.
--
nosy:
Changes by koobs koobs.free...@gmail.com:
--
components: +Tests
keywords: +needs review
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
Larry Hastings added the comment:
Those interested in this issue might also be interested in #19838, in which I
demonstrate that utime(path, NULL) can set mtime to an *earlier* time on ZFS on
Linux.
--
title: Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/
FFS,
Mark Lawrence added the comment:
Could we have a formal review of the patch please as Victor seemed fairly happy
with it in msg176881. Note that #16287 also refers to this issue.
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list
Changes by Claudiu.Popa pcmantic...@gmail.com:
--
nosy: +Claudiu.Popa
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list
Changes by Ed Maste carpedd...@gmail.com:
--
nosy: +Ed.Maste
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing
koobs added the comment:
I've moved both of the FreeBSD buildbot slaves off their ZFS-backed home
directories and back to good old UFS.
I want to ensure FreeBSD support continues to improve, and having slaves get
noticed when they fail or regress with ongoing development is a big part of
koobs added the comment:
I'm happy to move them back upon request, or create a FreeBSD/ZFS buildslave
specially for the job, just let me know.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
koobs added the comment:
There's some work that's been in the FreeBSD bleachers since Jul 2012 to add
futimens() and utimensat(), with some recent activity:
RFC: futimens(2) and utimensat(2) - Jul 2012
http://lists.freebsd.org/pipermail/freebsd-arch/2012-February/012409.html
RFC: futimens(2)
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
___
Python-bugs-list mailing list
STINNER Victor added the comment:
I didn't read the whole issue, but the following code makes sense.
+try:
+import posix
+except ImportError:
+# Windows has nanosecond utime resolution.
+UTIME_EPSILON = 2e-9
+else:
+import sysconfig
+if 'HAVE_UTIMENSAT' in
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,
Larry Hastings added the comment:
I don't know POSIX / UNIX all that well. Does it require that a stat call
updates atime? Because that's one of those how does it ever work
head-scratchers. (Maybe everybody always disables atime these days? I don't
think I do.)
--
Antoine Pitrou added the comment:
I don't know POSIX / UNIX all that well. Does it require that a stat
call updates atime? Because that's one of those how does it ever
work head-scratchers. (Maybe everybody always disables atime these
days? I don't think I do.)
I think most Linux
Trent Nelson added the comment:
Re: how did it ever work... on Solaris, because of the st_mtime failure, it
doesn't even get a chance to fail on the subsequent st_atime. I suspect the
only platform that's exercised the utimensat() to date is Linux, and either a)
os.stat() doesn't affect
Trent Nelson added the comment:
Here's a thought... why not alter the test to work with fixed times and
separate the atime tests from the mtime tests.
For atime, we can set utime(filename, (0.0, ...)) and see if a subsequent
os.stat() returns st_atime as 0.0 -- that'll tell us whether or not
Trent Nelson added the comment:
I've figured out what the primary problem is on these platforms: os.stat()
returns st_mtime and st_atime values with nanosecond resolution, but without a
corresponding utimensat(), we can only affect time with microsecond precision
via utimes().
Therefore, the
Larry Hastings added the comment:
Is there a different utime family function on these platforms that *can* write
atime/mtime with ns resolution?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
Trent Nelson added the comment:
There doesn't appear to be on FreeBSD. Although, on Solaris, -D__EXTENSIONS__
opens up access to utimensat() (at least on 11), so I'll factor that into
configure.ac.
--
___
Python tracker rep...@bugs.python.org
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15745
___
Trent Nelson added the comment:
This patch (surprisingly) seems to do the job quite nicely:
diff -r 1280b38fe583 Lib/test/test_os.py
--- a/Lib/test/test_os.py Tue Oct 16 23:14:03 2012 +1000
+++ b/Lib/test/test_os.py Tue Oct 16 21:25:36 2012 +
@@ -40,6 +40,20 @@
or
Larry Hastings added the comment:
You're a sneaky, naughty bunny. posix._have_functions indeed! I guess your
back was to the wall.
1)
If I follow your code correctly, when one has utimensat, the assertLess calls
using _t consider st0.st_mtime_ns st1.st_mtime_ns even if the left operand is
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
Trent Nelson added the comment:
Oh, and another quirk I noticed yesterday. I usually religiously disable
atime on all my filesystems. For whatever reason, it's not disabled on this
Solaris 10 box.
Turns out os.stat() was updating st_atime, which kind of throws a spanner in
the works for
Changes by Trent Nelson tr...@snakebite.org:
--
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
46 matches
Mail list logo
