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: os.stat fails for file pending delete on Windows
Type: Stage:
Components: Library (Lib), Windows Versions: Python 3.3, Python 3.4
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: brian.curtin, chris.jerdonek, jeremy.kloth, jkloth, loewis, pitrou, tim.golden
Priority: normal Keywords:

Created on 2012-08-04 16:07 by jkloth, last changed 2022-04-11 14:57 by admin.

File name Uploaded Description Edit jkloth, 2012-08-04 16:07 test case
Messages (6)
msg167414 - (view) Author: Jeremy Kloth (jkloth) * Date: 2012-08-04 16:07
os.stat fails when called on a file that is pending delete but is still in the directory listing.

This in turn causes os.path.exists to return the wrong result.

Attached is a test case demonstrating this broken behavior.
msg167415 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-04 16:17
How does it fail? Please paste the precise exception.
msg167416 - (view) Author: Jeremy Kloth (jkloth) * Date: 2012-08-04 16:22
Traceback (most recent call last):
  File "", line 12, in <module>
    print('stat', os.stat(pathname))
PermissionError: [Error 5] Access is denied: '\\Users\\Jeremy\\test.tmp'
msg167417 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-08-04 16:34
Why do you think the behavior is broken? It looks right to me - it's not possible to get file information for a file that is scheduled for deletion.

ISTM that rather os.path.exists has non-intuitive behavior; it shouldn't infer from the PermissionError that the file does not exist, but that it is not able to tell.

However, this is not a bug, but documented behavior, see
msg167418 - (view) Author: Jeremy Kloth (jeremy.kloth) Date: 2012-08-04 16:38
> Why do you think the behavior is broken? It looks right to me - it's not possible to get file information for a file that is scheduled for deletion.

However you can when using MSVCRT's stat() function or even
FindFirstFile directly.
msg201175 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-10-24 20:09
Had a to-and-fro on IRC with RDM who highlighted that an inconsistency between os.listdir and os.path.exists (the case here) is, at least, undesirable. As it stands, our os.exists on os.stat mechanism will fail because any attempt to get any kind of handle via CreateFile will fail once the file is unlinked. However, FindFirstFile succeeds (hence os.listdir).

I'll put forward a patch to see whether it's worth pursuing.
Date User Action Args
2022-04-11 14:57:33adminsetgithub: 59761
2013-10-24 20:09:41tim.goldensetmessages: + msg201175
2012-08-04 17:04:37chris.jerdoneksetnosy: + chris.jerdonek
2012-08-04 16:38:43jeremy.klothsetnosy: + jeremy.kloth
messages: + msg167418
2012-08-04 16:34:16loewissetmessages: + msg167417
2012-08-04 16:22:25jklothsetmessages: + msg167416
2012-08-04 16:17:19pitrousetmessages: + msg167415
2012-08-04 16:10:35jklothsetnosy: + jkloth
2012-08-04 16:10:12jklothsetnosy: + loewis, pitrou, tim.golden, brian.curtin, - jkloth
2012-08-04 16:07:42jklothcreate