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


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.