Mail Archives: cygwin/2002/04/10/10:46:42
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/
- Raw text -