Date:	Tue, 13 Jun 2000 13:35:17 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Mark E." <snowball3 AT bigfoot DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: tmpfile in DJGPP
In-Reply-To:	<39454330.19416.704D85@localhost>
Message-ID:	<Pine.SUN.3.91.1000613133432.16888V-100000@is>
MIME-Version:	1.0
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

On Mon, 12 Jun 2000, Mark E. wrote:

> > 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.

Yes, that's what I meant as well.  In other words, adding O_TEMPORARY
without handling the unlink problem is much less useful (although I
have nothing against such a feature per se).

> To set the flag inside the 'remove' function, DJGPP would have know (in my 
> opinion) the filename associated with the file descriptor.

Yes.

> 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.

A side note: SHARE will not help, since IIRC it generates Int 24,
which cannot be reliably caught by a DJGPP program.

- Raw text -