SUMMARY: Problems with tmpfile(3)

From: Amir Katz (matis!amir)
Date: Sun Aug 30 1992 - 18:39:31 CDT

Recently, I asked:

>> Gurus,
>> I'm using tmpfile(3). The man page claims that it calls tmpnam(3S). The man
>> page for tmpnam(3S), in turn claims that the temp files are created in a
>> directory specified in the header file stdio.h, which is /usr/tmp on my
>> SunOS 4.1.2.
>> When running my program, df shows that space is consumed in the root
>> partition, but du does not show any change in /, nor does find(1) find the
>> temp file.
>> I used ofiles, a public-domain program that shows the files used by a
>> program, and using the partition and inode, I called find with
>> find <partition> -inum <inode> -print
>> It showed bogus results.
>> - Does anyone know where the temp files are hiding?
>> - Also, does anyone know how does tmpfile take care of removing the files when
>> the process is terminated? Seems like there is an exit hook that the system
>> is calling to take care of that.

Once again the list comes through. Thanks, people.

Before summarizing, I must apologize: I'm well aware the /usr/tmp is a
symbolic link to /var/tmp on SunOS, but I did not state that in my mail, so
some people blasted me for doing 'df' and 'find' on the / partition while
the file is created in /usr/tmp. Sorry for that.

Anyway, the consensus can be best summarized by quoting the reply of Michael
Gordon (!mfg). Many other responses were also very informative.

>> Tmpfile opens the file and then unlinks it. The file isn't actually
>> deleted as long as something has it open, but unlink() removes the
>> directory entry for it so user processes don't see it. Ofiles digs
>> through the kernel data structures, which will still have an entry for
>> it. Find probably gets confused because although the file has an inode
>> and takes up disk blocks it no longer has a name. When the process
>> exits the operating system closes everything that is still open. This
>> removes the last reference to the file and so the disk space is
>> reclaimed. Below is the source to tmpfile() so you can see exactly
>> what it does.
>> FILE *
>> tmpfile()
>> {
>> char tfname[L_tmpnam];
>> register FILE *p;
>> (void) tmpnam(tfname);
>> if((p = fopen(tfname, "w+")) == NULL)
>> return NULL;
>> else
>> (void) unlink(tfname);
>> return(p);
>> }

Tom Slezak ( adds:

>> There is an ancient Unix hack of unlink(2)-ing a file immediately after
>> opening it, such that nobody else can see that file but it will not vanish
>> until the process that opened it completes. I suspect that tmpfile(2) is
>> using that trick, which would account for the action you observed.

Also, thanks for the person who flamed me for posting the question to

Thanks for the following people:

Birger A. Wathne
Claus Assmann!ca
Michael Gordon!M.F.Gordon
Steve Kilbane
Martin {martlbub} Kraegeloh PRI-MU.Prime.COM!krm
Donald McLachlan!don
Daniel Trinkle
David Wiseman magi@csd.uwo.CA
Brian Katzung katzung@{i88.isc,sbcoc}.com
Robert E. Landsparger
Tom Slezak (
Gregg Siegfried
Dan Schlitt!dan
Skip Gilbrech
Brian Utterback
Steve Harris uunet!etnibsd!vsh
Dwight A. Ernest
Barry Margolin
Michael Sullivan uunet.UU.NET!trdlnk!mike

/* ----------------------------------------------------------- */
/*  Amir J. Katz             |   amir@matis.ingr.COM           */
/*  System Specialist        |   Voice:  +972 52-584684        */
/*  SEE Technologies Ltd.    |   Fax:    +972 52-543917        */
/* ............ Solaris 2.0 - The Final Frontier ? ........... */

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:49 CDT