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 (ee.edinburgh.ac.uk!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 (slezak@llnl.gov) 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
sun-managers...
Thanks for the following people:
Birger A. Wathne birger@vest.sdata.no
Claus Assmann idefix.informatik.uni-kiel.dbp.de!ca
Michael Gordon ee.edinburgh.ac.uk!M.F.Gordon
Steve Kilbane Steve_Kilbane@gec-epl.co.uk
Martin {martlbub} Kraegeloh PRI-MU.Prime.COM!krm
Donald McLachlan mars.dgrc.doc.ca!don
Daniel Trinkle trinkle@cs.purdue.edu
David Wiseman magi@csd.uwo.CA
Brian Katzung katzung@{i88.isc,sbcoc}.com
Robert E. Landsparger rel@mtu.edu
Tom Slezak slezak@llnl.gov (tom@yac.llnl.gov)
Gregg Siegfried grs@claircom.com
Dworkin dworkin@rootgroup.com
Dan Schlitt ees1s0.engr.ccny.cuny.edu!dan
Skip Gilbrech skip@fsg.com
Brian Utterback blu@mc.com
Steve Harris uunet!etnibsd!vsh
Dwight A. Ernest dwight@hyphen.com
Barry Margolin barmar@think.com
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