Date:	Sun, 17 Jun 2001 14:39:25 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Our unlink() isn't POSIX
In-Reply-To:	<CAEGKOHJKAAFPKOCLHDIGEFNCEAA.tim.van.holder@pandora.be>
Message-ID:	<Pine.SUN.3.91.1010617143521.12677L-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 17 Jun 2001, Tim Van Holder wrote:

> > The results of deleting an open file depend on the underlying OS: Windows
> > NT actually supports the Posix behavior; Windows 9X refuses to remove the
> Does that mean that our unlink/rename follow Posix on NT/2000, or is it
> simply that NT/2000 supports the behaviour?

The OS does it.  This kind of thing is impossible to provide on the 
application level, for the reasons I explained.

> In any case, I'll have to stick to the very ugly
> 
>   for (i = 3; i < 256; ++i)
>     close (i);
> 
> before the cleanup function (on Win32, _fcloseall() is used, which I assume
> does mainly the same thing).

We have a similar function, but I don't see how would this help you with 
the problem at hand.  You still cannot remove an open file without 
risking trouble.

> +The @sc{posix} specification requires this removal to be delayed until the
> +file is no longer open.  Because this is not feasible on most systems
> +supported by DJGPP (Windows NT and 2000 being the exceptions), this
> +implementation of @code{unlink} does not fully comply with the specs; if
> +the file you want to unlink is open, @code{unlink} will fail.

Thanks.

The ``unlink will fail'' part is IMHO too vague and might mislead 
someone.  I suggest to describe what happens on each OS, because ``fail'' 
is ambiguous.

- Raw text -