Unlinking Files on Windows

This page is intended for developers.

This page describes what happens when Python's 'os.unlink(f)' is called on Windows.

1. File opened using Python's "open"

If the file f itself or any hardlinked copy of f has been opened for reading by another process using Python's 'open()', then 'os.unlink(f)' will raise

WindowsError: [Error 32] The process cannot access the file because it is being
used by another process: <f>

2. File opened using Mercurial's "posixfile"

If the file f has been opened for reading by another process with 'posixfile(f)', calling unlink will send that file into a "scheduled delete" state.

Scheduled delete has the following characteristics:

• (a) the entry in the directory for f is still kept

• (b) calling 'fd = posixfile(f, 'w')' will raise 'IOError: [Errno 13] <f>: Access is denied'

• (c) calling 'os.rename(f, f+'.foo')' will raise 'WindowsError: [Error 5] Access is denied'

• (d) calling 'os.lstat(f)' will raise 'WindowsError: [Error 5] Access is denied: <f>'

• (e) calling 'os.path.exists(f)' returns False

Scheduled delete is left as soon as the other process closes the file.

3. See also

• issue2524: "opener loses files on 'w'rite for open files on Windows"

• issue2543: "os.unlink deletes wrong file on windows share served by Samba"

• How Mercurial could be made working with Virus Scanners on Windows

CategoryInternals