Mail Archives: djgpp-workers/2001/06/18/05:47:54
On Mon, 18 Jun 2001, Eli Zaretskii wrote:
> But I don't really understand what problem is this close-all code
> supposed to solve? Could you elaborate on what does lclint do that
> forces you to use such techniques?
It's the old usual Unix technique for getting a 'safe' temporary file:
open() a file under /tmp or wherever, then immediately unlink() it. The
result is an open file handle the program can work with, which will
automatically be closed as the process ends, since that open handle is the
only reason for the OS not to have deleted the file, yet.
Since there is no other way left to access that file, in particular no
telltale directory entry below /tmp, both accidental and purposeful
attacks upon that temporary file are less likely to occur. On Linux,
this not quite true any longer: you can `ls /proc/<PID>/fd' to get a list
of all file handles owned by an application, as pseudo-symlinks to their
numeric inode representation.
The whole idea is based upon Unix' way of decoupling a file's content
(essentially, the inode) from it's name entry in one or more directory
listings. And upon the fact that there is a multi-processing-aware
filesystem layer in the OS, in the first place :-)
Within DOS philosophy, the rationale would be: there is only one app
active, and this app is supposed to *know* which files it has opened,
at any time, so it can easily avoid removing them accidentally.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -