RE: REPOST: unlink semantics

RE: REPOST: unlink semantics

[Robert Collins]

> -----Original Message-----
> From: Chris January [mailto:chris@atomice.net] 
> Sent: Wednesday, April 10, 2002 9:57 PM
> To: cygwin@cygwin.com
> Subject: REPOST: unlink semantics
> 
> 
> With respect to the 'Infinte Loop in "rm -fr"' thread, I 
> believe the current semantics of unlink on Cygwin to be 
> inconsistent with SuSv2.
> 
> SuSv2 specifies the following:

SuS assumes files can be removed/deleted while in use. 

> Cygwin's current implementation of unlink is not consistent 
> with the following part: "If one or more processes have the 
> file open when the last link is removed, the link will be 
> removed before unlink() returns, but the removal of the file 
> contents will be postponed until all references to the file 
> are closed." At present Cygwin delays not only the removal of 
> the file contents, but also the removal of the link (i.e. the 
> directory entry).

Patches to correct this gratefully accepted. Don't forget to test on
win9x and NT4. Also be sure to test what happens when you delete a .dll
out from under a program on win9x.

> As a suggested fix, path_conv::check could 
> returns ENOENT for a file if it appears in the delqueue. 

This introduces it's own problems: what happens when the application
then tries to create a new file with that file name? Do we give it a
random temporary name? What happens when the app then calls a non-cygwin
program with the file name.... oops!

Anyway, food for thought.

Rob

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: REPOST: unlink semantics

[Corinna Vinschen]

On Wed, Apr 10, 2002 at 10:20:04PM +1000, Robert Collins wrote:
> > As a suggested fix, path_conv::check could 
> > returns ENOENT for a file if it appears in the delqueue. 
> 
> This introduces it's own problems: what happens when the application
> then tries to create a new file with that file name? Do we give it a
> random temporary name? What happens when the app then calls a non-cygwin
> program with the file name.... oops!

Yes, you can't make everyone happy.  The Windows semantics when
deleting a file in use is so different from POSIX, that you will
always find a situation which won't work as in POSIX.  Regardless
of the effort you make to "get it right".

I don't think it's worth it.  The whole delqueue approach is just
a crook and will always be.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: REPOST: unlink semantics

[Randall R Schulz]

Corinna,

I am not intimately familiar with the issues, nor do I know the history of 
the delqueue approach, but isn't it just trying too hard to do something 
that cannot really be done well enough to be worth trying?

Would it not be better to simply reflect the failure to the application 
level (caller of unlink(2)) and let it deal with the failure? Does that 
break even more things?

To me, having "rm -fr" loop infinitely is pretty undesirable behavior. Is 
it worse than what would happen if unlink(2) could fail under Cygwin in 
cases where it would not under a genuine Unix system?

Curious,

Randall Schulz
Mountain View, CA USA


At 06:35 2002-04-10, Corinna Vinschen wrote:
>On Wed, Apr 10, 2002 at 10:20:04PM +1000, Robert Collins wrote:
> > > As a suggested fix, path_conv::check could
> > > returns ENOENT for a file if it appears in the delqueue.
> >
> > This introduces it's own problems: what happens when the application
> > then tries to create a new file with that file name? Do we give it a
> > random temporary name? What happens when the app then calls a non-cygwin
> > program with the file name.... oops!
>
>Yes, you can't make everyone happy.  The Windows semantics when deleting a 
>file in use is so different from POSIX, that you will always find a 
>situation which won't work as in POSIX.  Regardless of the effort you make 
>to "get it right".
>
>I don't think it's worth it.  The whole delqueue approach is just a crook 
>and will always be.
>
>Corinna


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: REPOST: unlink semantics

[Robert Collins]

> -----Original Message-----
> From: Randall R Schulz [mailto:rrschulz@cris.com] 
> Sent: Thursday, April 11, 2002 12:45 AM

> Does that 
> break even more things?

IIRC, Yes.

Rob

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

REPOST: unlink semantics

[Chris January]

With respect to the 'Infinte Loop in "rm -fr"' thread, I believe the current
semantics of unlink on Cygwin to be inconsistent with SuSv2.

SuSv2 specifies the following:
The unlink() function removes a link to a file. If path names a symbolic
link, unlink() removes the symbolic link named by path and does not affect
any file or directory named by the contents of the symbolic link. Otherwise,
unlink() removes the link named by the pathname pointed to by path and
decrements the link count of the file referenced by the link.
When the file's link count becomes 0 and no process has the file open, the
space occupied by the file will be freed and the file will no longer be
accessible. If one or more processes have the file open when the last link
is removed, the link will be removed before unlink() returns, but the
removal of the file contents will be postponed until all references to the
file are closed.

Cygwin's current implementation of unlink is not consistent with the
following part: "If one or more processes have the file open when the last
link is removed, the link will be removed before unlink() returns, but the
removal of the file contents will be postponed until all references to the
file are closed." At present Cygwin delays not only the removal of the file
contents, but also the removal of the link (i.e. the directory entry). This
causes problems with programs that expect the post-condition of unlink to be
that the directory entry for the specified file is removed if unlink returns
0. rm is one example of such a program and this inconsistency is the cause
of the "infinite loop" problem reported in the other thread.
As a suggested fix, path_conv::check could returns ENOENT for a file if it
appears in the delqueue. I would submit a patch for this, but I am not 100%
sure how the delqueue is protected from multiple threads accessing it at the
same time. _readdir would also have to check for a file's presence in the
delqueue.

Chris




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/