Date: Tue, 13 Jun 2000 13:36:32 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: DJ Delorie cc: djgpp-workers AT delorie DOT com Subject: Re: tmpfile in DJGPP In-Reply-To: <200006130301.XAA02001@envy.delorie.com> Message-ID: 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, DJ Delorie wrote: > I don't think there *is* a reliable way of doing this, especially when > you consider parent/child processes. Consider a parent that has a > file open, and it spawns a child that deletes the file. These cases are part of the challenge ;-). One possibility is to add code to crt1.c which walks the JFT and notes all the handles that are already in use: these are the handles inherited from the parent, which should not be deleted. The child could tell the parent about such handles e.g. via the transfer buffer, if the application attempts to delete them. Another piece of relevant info is that on Windows 9X and DOS 7.0+ there's a system call which enumerates all open files on a given drive (Int 21h/AX=440Dh/CX=086Dh). This can be used, albeit at a price of slowing down the `remove' calls. On plain DOS, we could write code which looks at the SFT entry for the handle and finds out the reference count of that handle: if it's more than 1, do not delete and tell the parent about that. Finally, on NT (and possibly Windows 2K) you don't need to do anything: just remove the file as usual, and the OS does the rest, like on Unix.