Date: Tue, 30 May 2000 11:08:47 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Alain Magloire cc: djgpp-workers AT delorie DOT com Subject: Re: tmpfile in DJGPP In-Reply-To: <200005300200.WAA11609@qnx.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, 29 May 2000, Alain Magloire wrote: > fd = open ("myfile", ...); > unlink ("myfile"); /* remove ("myfile"); */ > write (fd, buffer, sizeof (buffer)); > read (fd...); > close(fd); > > Somebody was going to come up with a hack where the unlink()/remove() > was delayed until termination of the program or close()/fclose(). Nothing's changed: you still cannot do this and hope to succeed (it works on NT, fails with an error code on Windows 9X, silently corrupts your filesystem on plain DOS). To make the removal deferred until program's exit, we will need to introduce a new data structure to track the files that were open, together with their names, so that we could see when the program tries to remove them. I'm not sure this is worth the hassle (but volunteers are welcome, as always ;-). > Now how do you guys handle tmpfile() ? tmpfile uses a special flag in the FILE object, which causes `fclose' to remove it (the exit code walks all the FILE objects and fcloses them one by one). > Meaning is it guaranteed to be deleted ? Only if the program exits normally. > I do not remember if POSIX/ANSI relaxed the wording to not > required the file to not be nuked if not terminated by exit(), > for stdio::tmpfile(). Can someone look it up and tell? I'd guess Microsoft won't let them require the Unix behavior, since it is not supported on anything but NT. > I'm asking this because of some code and would certainly like > to make life easier in the long run when porting will be an issue. I have just bumped into a similar problem in Groff. After trying some tricks, I just bit the bullet and added code to record the names of all the temporary files on a special structure and register an atexit function that removes them in one go. I think that adding such code to the application is much simpler than making the library support this transparently. It also makes the code more portable to non-DJGPP environments, such as Mingw.