From: "Mark E." <snowball3 AT bigfoot DOT com>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Date: Mon, 12 Jun 2000 20:08:16 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: tmpfile in DJGPP
Message-ID: <39454330.19416.704D85@localhost>
References: <39438707 DOT 29061 DOT 505C1E AT localhost>
In-reply-to: <Pine.SUN.3.91.1000612153746.5082J-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp-workers AT delorie DOT com

> I thought that this was supposed to solve the situation where the
> application deletes an open file, no?  If so, the challenge is to turn
> on this flag automatically inside the `remove' function.

The objective, as I see it, is to provide a reliable way to port Unix code 
that uses the 'open/unlink/close' way of making a temporary file.

To set the flag inside the 'remove' function, DJGPP would have know (in my 
opinion) the filename associated with the file descriptor. Otherwise, it 
would have to try and remove a possibly open file and rely on file locking 
(and that SHARE is running in plain DOS)  to signal the file is still open, 
and then have 'remove' or 'unlink' set the O_TEMPORARY flag accordingly. But 
by then the handle could have been duplicated and that would throw off the 
internal reference count used by the 'remove-on-close' code. I checked to see 
what Cygwin does, and when it tries to delete a file currently in use, it 
adds the filename to a list. And when close() is called, it tries to delete 
all the files on that list. But this method would also require the presence 
of share.exe or a DOS VM.

If anyone has an idea for the 'remove' magic, I'd sure like to hear it.

Mark