This is the mail archive of the cygwin@cygwin.com 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]

Re: REPOST: unlink semantics


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/


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