Date: Sun, 17 Jun 2001 13:20:32 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder cc: DJGPP-Workers Subject: Re: Our unlink() isn't POSIX In-Reply-To: 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 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 ;-)