This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

unlink()'s not quite POSIX behavior.

It appears that currently unlink will not immedately remove a file (that has only one link) if a handle to the file is open, but will flag it for deletion once the file handle closes.

This is causing a problem with Python 3000.

POSIX says:

When the file's link count becomes 0 and no process has the file open,
the space occupied by the file shall be freed and the file shall no longer
be accessible. If one or more processes have the file open when the last
link is removed, the link shall be removed before unlink() returns, but
the removal of the file contents shall be postponed until all references
to the file are closed.

AIUI, Windows NT had a design goal of allowing a complient implementation of POSIX to be implmented in a subsystem (along with userespace utilities). (Hence services for unix).

Could we at least simulate the behavior by moving the file out of the way (simultaionsly renaming it to something unique),
and forcing it into the delqueue? (by Setting the FILE_DISPOSITION_INFORMATION's DeleteFile flag to true?)

Wait a moment, that looks to be exactly what unlink_nt is doing?
What is going on?

(The problem is with a call in Python3k getting a "Permission denied" (ERRNO 13) error when attempting to create a file shortly after it has been deleted with unlink. That seems to be consistant with standard windows behavior for deleting a file, as trying to create it again before the last handle is closed would return an ERROR_ACCESS_DENIED.)

However, it looks like with unlink_nt that should not be happening, right?

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]