On Tue, Oct 31, 2017 at 1:16 PM, Henk Zevenhuizen
<henk.zevenhui...@gmail.com> wrote:
>
> Then i get the message: "after", the file is still there and i cannot delete
> the through windows explorer (permission denied)
> the only way to delete the file is killing python
Does Explorer explicitly tell you "permission denied" or "file access
denied", or is it a "sharing violation" or "file in use" error?
The common case is a sharing violation (error 32). Deleting a file
requires opening it with delete (DELETE) access. Whether or not that's
allowed depends in part on how the file is already open. Filesystems
maintain counts of the number of times a file is open; the number of
opens that have read (or execute), write (or append), or delete
access; and the number that share read (or execute), write (or
append), or delete access. In order for an open with delete access to
not fail with a sharing violation, all previous opens must share
delete access. Also, if any previous open has delete access, then the
current open has to share delete access. IMO, access sharing should
not be called a 'lock'. It could be confused with Windows file
locking, which is a completely different system. File locking does not
prevent file deletion.
For example, Python defaults to opening files with read and write
sharing, but not delete sharing:
>>> fd = os.open('test.txt', os.O_CREAT)
>>> os.remove('test.txt')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
WindowsError: [Error 32] The process cannot access the file
because it is being used by another process: 'test.txt'
Once the file handle is closed, os.remove (WinAPI DeleteFile) succeeds:
>>> os.close(fd)
>>> os.remove('test.txt')
>>> os.listdir('.')
[]
If, on the other hand, Explorer is subsequently being denied delete
access (error 5), then maybe your Python program actually has the file
open with delete sharing. In this case, initially 'deleting' the file
will succeed, but it won't be unlinked, and re-opening the file will
fail with access denied.
For example, the O_TEMPORARY flag opens a file with delete sharing:
>>> fd = os.open('test.txt', os.O_CREAT | os.O_TEMPORARY)
>>> os.remove('test.txt')
DeleteFile succeeds this time, but in Windows that only means the
file's delete disposition is set. This is a flag on the underlying
file/stream control block (FCB or SCB) that tells the filesystem to
unlink the file when all existing references to it have been closed.
We still have a handle open, so the file is not unlinked, as you can
see via listdir:
>>> os.listdir('.')
['test.txt']
When the delete disposition is set, it's impossible to re-open the
file for any access, even the most basic access to stat() file
metadata:
>>> os.stat('test.txt')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
WindowsError: [Error 5] Access is denied: 'test.txt'
The file is unlinked after the handle is closed:
>>> os.close(fd)
>>> os.listdir('.')
[]
That would have happened even without calling os.remove because
O_TEMPORARY flags the opened file as delete-on-close.
_______________________________________________
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32
