From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: Re: Our unlink() isn't POSIX
Date: Sun, 17 Jun 2001 20:20:44 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDIEEGACEAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <2110-Sun17Jun2001181945+0300-eliz@is.elta.co.il>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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
Precedence: bulk

> We pass the call to the OS.  What happens next is entirely up to the
> OS.  NT behaves like a Unix filesystem.  I'd expect W2K to do the
> same, but I think we had better test this first, since we already have
> quite a few aspects where W2K behaves differently from NT (to the
> worse :-().

Ah - ok.  Updated docs patch below.

> > so I went with a loop (seemed safe enough).
> Not for buffered stdio streams: you could lose the buffered
> characters.
Oops.

>  (I assume that _fcloseall, given its name, does an
> `fclose' on every FILE object that is still open.)

That's what its docs say - it closes all files, except for stdin, stdout
and stderr (and on DOS stdaux and stdprn).

> _fwalk walks all
> the FILE objects and fflushes them before closing, not just closes the
> handle.

Will look into it.  This would not catch files opened with regular open()
though, would it?  And are stdin/stdout/stderr part of the list of
FILE*s walked by _fwalk?


Index: unlink.txh
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/posix/unistd/unlink.txh,v
retrieving revision 1.2
diff -u -u -r1.2 unlink.txh
--- unlink.txh	1998/09/27 15:22:28	1.2
+++ unlink.txh	2001/06/17 18:09:55
@@ -11,6 +11,19 @@
 
 This function removes a file from the file system. 
 
+@subheading Caveat
+
+The @sc{posix} specification requires this removal to be delayed until the
+file is no longer open.  Due to problems with the underlying operating
+systems, this implementation of @code{unlink} does not fully comply with
+the specs; if the file you want to unlink is open, you're asking for
+trouble - how much trouble depends on the underlying OS.  On NT (and
+possibly on 2000 as well), you get the behaviour @sc{posix} expects.
+On Win9x and WinME (and possibly WinXP as well), the removal will simply
+fail (@code{errno} gets set to @code{EACCES}).  On DOS, removing an
+open file could lead to filesystem corruption if the removed file is
+written to before it's closed.
+
 @subheading Return Value
 
 Zero on success, nonzero on failure. 
@@ -18,6 +31,7 @@
 @subheading Portability
 
 @portability !ansi, posix
+@port-note Not fully compliant with the POSIX specification (cfr. supra).
 
 @subheading Example