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
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


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.