[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[STINNER Victor]

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 (ex: it's usually the case on Linux), whereas the FAT filesystem has as resolution of 2 seconds.

os.utime() can have a resolution of 1 us (ex: FreeBSD) whereas the ZFS filesystem has a resolution of 1 ns.

Currently, test_os.test_*utime*_ns checks that os.utime() is able to copy the timestamp of a file 1 to a file 2. Problem: we don't know the resolution of the timestamp of the file 2. We can get the resolution of the C internal function used by os.utime(). It is implemented in the attached test_os.patch. But it's much more complex to get the timestamp resolution of the filesystem, in a portable way.

Random thoughts:

* use a timestamp with a resolution of 1 us, smaller than 2^24 to avoid rounding issues. Example: (atime=1.002003, mtime=4.005006)?

* compute the effective utime resolution: call os.utime() with a well known timestamp with a resolution of 1 nanosecond (smaller than 2^24 to avoid rounding issues) and call os.stat() to check which digits were preserved

test_os must not depend too much on the filesystem. I don't think that we should implement complex code just to check a simple field in the os.stat_result structure. The first idea (call utime with a fixed number, don't rely on an unknown file timestamp) is probably enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15745>
_______________________________________