> -Original Message-
> From: Randall R Schulz [mailto:[EMAIL PROTECTED]]
> 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.h
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
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 n
> -Original Message-
> From: Chris January [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 10, 2002 9:57 PM
> To: [EMAIL PROTECTED]
> Subject: REPOST: unlink semantics
>
>
> With respect to the 'Infinte Loop in "rm -fr"' thread, I
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
> 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.
Sorry, _readdir would also have to check for a file
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
7 matches
Mail list logo
