kern/73492: Wanted: Reliable Temporary Files

Ronald F.Guilmette rfg at
Wed Nov 3 11:20:20 PST 2004

>Number:         73492
>Category:       kern
>Synopsis:       Wanted: Reliable Temporary Files
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          change-request
>Submitter-Id:   current-users
>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 4.10-RELEASE FreeBSD 4.10-RELEASE #0: Wed Oct 27 13:02:03 PDT 2004 rfg at 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);
		unlink (tempfile_path);

	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 mailing list