Mail Archives: djgpp-workers/2001/06/17/06:19:06
On Sun, 17 Jun 2001, Tim Van Holder wrote:
> I ran across a problem when working on lclint: it assumes
> that it can simply unlink all it's temporary files without
> closing them first; this is a valid assumption according to
> the POSIX spec, but isn't true for our implementation.
Welcome to the party. This issue is one of the major headaches in
porting large applications which unconditionally assume Posix behavior.
It is also a source of many bugs in such ports.
The results of deleting an open file depend on the underlying OS: Windows
NT actually supports the Posix behavior; Windows 9X refuses to remove the
file (and you get an error message from `unlink' or `remove'), DOS
blindly removes the file and risks corrupting the FAT when the program
exits and DOS closes the file (which might involve flushing buffers using
a stale file handle).
> Is it possible for us to know if we have a given file open?
No, not without walking internal OS data structures. There's no OS
service for this on most systems supported by DJGPP. And even if there
were such a service, there's not much we could do with it (see below).
> If so, would it be possible for unlink to set the 'remove on
> close' flag?
This wouldn't solve the problem, because in most of these cases, the
program never bothers to close the file explicitly; it relies on the OS
to do that when the program exits.
And there's also the issue of a file opened by more than one program
(say, a parent and a child), where what a single program knows is not
enough to make the right decision. The most frequent incarnation of this
is redirection of file handles inherited by the child program.
> If this is not feasible, at the very least the docs for unlink
> should be amended to say how our implementation differs from
> the POSIX spec.
Patches for the docs are always welcome ;-)
- Raw text -