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.

Title: zero-valued timestamps are mishandled by os.stat() in Windows
Type: behavior Stage:
Components: Library (Lib), Windows Versions: Python 3.10, Python 3.9, Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: CristiFati, eryksun, iritkatriel, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords: patch

Created on 2015-04-14 11:56 by CristiFati, last changed 2022-04-11 14:58 by admin.

File name Uploaded Description Edit
Python-2.7.8-invalid_filetimes.patch CristiFati, 2015-04-14 11:56
Messages (4)
msg240875 - (view) Author: Cristi Fati (CristiFati) * Date: 2015-04-14 11:56
In WinPE environment (at least this is where I found it, but there might be cases where this issue could be spotted in normal Windows), some folders might have some of the FILETIME structures reset (because of RAMDrive?). When the conversion between WIN style (100 * nsecs from  1601/01/01) to UX style (secs from 1970/01/01) is taking place (epoch is being substracted), it could yield invalid filetime values (that will be reported by os.stat).

The attached patch simply goes around this initializing the UX timestamps to 0.

It was found in Python-2.7.3, the patch is for 2.7.8, but I think it can be reproduced with all the newer versions.
msg382223 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-12-01 09:21
The code of posixmodule.c looks very different now. It this issue still relevant?
msg382251 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2020-12-01 14:06
> The code of posixmodule.c looks very different now.

The conversion code was moved to FILE_TIME_to_time_t_nsec() in Python/fileutils.c. 

time_t is a signed 64-bit integer type, so there's no immediate problem storing 1601-01-01 as the negative (pre-epoch) Unix timestamp -11644473600. But there are indirect problems with using negative Unix timestamps in Windows. In particular, datetime.fromtimestamp doesn't support them:

    >>> datetime.fromtimestamp(-11644473600)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [Errno 22] Invalid argument
msg388116 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-03-04 18:14
For example, the named-pipe filesystem (NPFS), doesn't return timestamps for pipes in the directory listing, so the timestamps are all 0 (i.e. 1601-01-01):

    >>> write_time = win32file.FindFilesW('//./pipe/*')[0][3]
    >>> format(write_time, '%Y-%m-%d %H:%M')
    '1601-01-01 00:00'

    >>> next(os.scandir('//./pipe')).stat().st_mtime

I agree that a zero-valued NT timestamp should be converted to a zero-valued Unix timestamp. No one has a file that was created, modified, changed, or accessed in 1601.

As mentioned above, the 1601 date doesn't roundtrip in Windows as a Unix timestamp since dates before the Unix epoch aren't supported:

    >>> write_time.timestamp()
    >>> datetime.fromtimestamp(write_time.timestamp())
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [Errno 22] Invalid argument
Date User Action Args
2022-04-11 14:58:15adminsetgithub: 68134
2021-03-04 18:14:22eryksunsettitle: Invalid timestamps reported by os.stat() when Windows FILETIME structures are mistakenly reset. -> zero-valued timestamps are mishandled by os.stat() in Windows
nosy: + paul.moore

messages: + msg388116

versions: + Python 3.8, Python 3.9, Python 3.10, - Python 2.7
components: + Library (Lib), - Interpreter Core
2020-12-01 14:06:58eryksunsetstatus: pending -> open
nosy: + eryksun
messages: + msg382251

2020-12-01 09:21:59iritkatrielsetstatus: open -> pending
nosy: + iritkatriel
messages: + msg382223

2015-04-14 11:56:59CristiFaticreate