Mail Archives: djgpp-workers/2001/06/17/11:21:31
> 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.
- Raw text -