Mail Archives: djgpp-workers/2000/05/30/04:16:25
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.
- Raw text -