Date:	Sun, 11 Apr 1999 13:53:08 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: fflush question
In-Reply-To:	<199904090117.VAA28719@spock2.ECE.McGill.CA>
Message-ID:	<Pine.SUN.3.91.990411135235.28502G-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Thu, 8 Apr 1999, Alain Magloire wrote:

> The explanation makes me wonder about a practice use by lots
> of Unix programmers for temp files. A file is created and deleted
> fd = create();
> unlink(fd);
> Even if the file is unlink .i.e not visible in the file system
> namespace, you can still read/write to it. This is common practice.
> Is it possible on DJGPP ?

Yes and no ;-).

Again, this is not a DJGPP issue, it's the underlying OS.  The proof?
The above paradigm will work on NT *exactly* as a Unix programmer
would expect; will silently fail to remove the file (and may corrupt
your disk) in plain DOS; and will cause `unlink' to return an error
code (EACCES, of course ;-) in Windows 9X -- all these using the same
DJGPP executable.

(I know because I once tested this for the Textutils maintainer.
Textutils use this paradigm, and so they have a special provision for
systems which don't support it.)

However, please note that unlink-while-open is a different misfeature,
separate from the fflush/ffsync problem we were discussing.

- Raw text -