This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Arfrever, BreamoreBoy, Claudiu.Popa, emaste, harrison.grundy, jcea, koobs, larry, pitrou, r.david.murray, trent, vstinner
Date 2015-06-11.22:27:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.
Date User Action Args
2015-06-11 22:27:56vstinnersetrecipients: + vstinner, jcea, pitrou, larry, trent, Arfrever, r.david.murray, Claudiu.Popa, BreamoreBoy, koobs, emaste, harrison.grundy
2015-06-11 22:27:56vstinnersetmessageid: <>
2015-06-11 22:27:56vstinnerlinkissue15745 messages
2015-06-11 22:27:56vstinnercreate