kern/73492: Wanted: Reliable Temporary Files
rfg at monkeys.com
Wed Nov 3 11:20:20 PST 2004
>Synopsis: Wanted: Reliable Temporary Files
>Arrival-Date: Wed Nov 03 19:20:20 GMT 2004
>Originator: Ronald F. Guilmette
>Release: FreeBSD 4.10-RELEASE i386
Infinite Monkeys & Co.
System: FreeBSD segfault.monkeys.com 4.10-RELEASE FreeBSD 4.10-RELEASE #0: Wed Oct 27 13:02:03 PDT 2004 rfg at segfault.monkeys.com:/usr/src/sys/compile/rfg20041027 i386
Consider the following code to create a "temporary" file which, it
is hoped, will be removed entirely from the file system upon program
completion, or upon the last close of the associated open fd, which-
ever comes first:
fd = open (tempfile_path, O_CREAT|O_RDWR, 0600);
In general, this code sequence will be sufficient to insure that the
created temporary file will be removed from the file system upon the
final close of the associated fd. The temporary file may perhaps
_not_ be removed however in cases where a signal is received between
the time the file is actually created, and the time the unlink becomes
This problem may be mitigated somewhat by blocking all blockable sig-
nals just before the call to open() and then unblocking them all again
just after the call to unlock(). The problem with this solution how-
ever is that the kernel prevents SIGKILL from being blocked by a user-
land program. Thus, if a SIGKILL is received between the time the
file is created and the time the unlink() becomes effective, the
``temporary'' file will remain in existance, thereby polluting the
file system with undesirable cruft.
Write a program containing the above code snippet, and then send it
a SIGKILL at Just The Right Moment.
This is a Request For Enhancement.
In my opinion, it would be Very Very Nice to have a new O_* option
bit which could be passed to the open(2) kernel primitive. One
possible sensible name for such a new option would be `O_UNLINK'.
The effect of such a new option would simply be to cause the kernel
to unlink the file from the file system (if permitted, based on
the permissions of the containing directory, and upon the UID of
the process that called open() with this new O_UNLINK option) either
(a) immediately, as soon as the open has been successfully completed,
or else (b) at the time of the last close of the relevant fd.
P.S. The justification for the proposed O_UNLINK option is essentially
identical to the justification for the O_EXLOCK and O_SHLOCK open(2)
options -- Here again we have a case where it is clearly useful to
have an additional operation applied to the file, atomically (at
least as far as userland processes are concerned) at the time of the
file open operation.
More information about the freebsd-bugs