Date: Sun, 17 Jun 2001 18:19:46 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
Message-Id: <2110-Sun17Jun2001181945+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <CAEGKOHJKAAFPKOCLHDIGEFOCEAA.tim.van.holder@pandora.be>
Subject: Re: Our unlink() isn't POSIX
References:  <CAEGKOHJKAAFPKOCLHDIGEFOCEAA DOT tim DOT van DOT holder AT pandora DOT be>
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

> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Sun, 17 Jun 2001 16:47:31 +0200
> 
> > > > 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.
> 
> What I meant was: does the libc code stop you, or will it simply pass the
> rename call through to the OS (with potentially disastrous results on plain
> DOS, and Posix behaviour on NT/2000)?

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 :-().

> > > 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
> 
> Oh - I checked the libc reference but couldn't find one

It's undocumented ;-)  It's called __stdio_cleanup_proc; see
src/libc/ansi/stdio/stdiohk.c.  Or just call _fwalk yourself; _fwalk
*is* documented.

> so I went with a loop (seemed safe enough).

Not for buffered stdio streams: you could lose the buffered
characters.  (I assume that _fcloseall, given its name, does an
`fclose' on every FILE object that is still open.)  _fwalk walks all
the FILE objects and fflushes them before closing, not just closes the
handle.