Re: unlink()'s not quite POSIX behavior.

2007-08-01 Thread Linda Walsh

Joe Smith wrote:

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
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?

(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?

>
Nevermind. I see that the relavent changes to NT_unlink are just very 
recent, and the only problem is that the latest cygwin dll does not 
incldue those changes yet.> 

-

I seem to remember being told that changing the rename function
to work in this, POSIX-compatible way, was impossible with cygwin's current
fork implementation -- and that Cygwin would have to keep track of
what files have been renamed (if any were DLL's) and propagate changes
to child processes (after a fork call) so they could correctly pull
in contents of "old, replaced DLL's".

Is this change to fork something that is being worked on?  I.e.
will we be able (at an application (setup.exe or cygperl replacing DLL's)
level) to rename "in-use" DLL's and copy in new versions?

I thought Eric indicated that this tracking would make an already
slow process even slower(?)  and wasn't worth it.
(http://sourceware.org/ml/cygwin/2006-12/msg00906.html)

Has this changed?  Or, more accurately, is this about to change? Was
it decided to go with the (seemingly) POSIX correct action to allow
the "rename-to-tmp+copy-in-new-DLL" (Rtt+CinD) to work?  Will
Cygwin be keeping track of the old "deleted" (but still in-use
via a cygwin open Filehandle) libraries to duplicate into new
children processes?

I seemed to remember feeling my "hand slapped" at suggesting
we use "Rtt+CinD" as it wouldn't be practical to implement.
Maybe the open-handle->"deleted file" idea isn't that expensive
to implement afterall?  (Despite it being a RPITA; hail emperor bill).


Linda

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: unlink()'s not quite POSIX behavior.

2007-07-31 Thread Joe Smith


"Joe Smith" wrote in message news:[EMAIL PROTECTED]

Nevermind. I see that the relavent changes to NT_unlink are just very 
recent, and the only problem is that the latest cygwin dll does not incldue 
those changes yet.
You can ignore the previous message. 




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



unlink()'s not quite POSIX behavior.

2007-07-31 Thread Joe Smith
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:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/