Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!news@seismo.CSS.GOV@sun.UUCP
From: news@seismo.CSS.GOV@sun.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Message-ID: <8612290824.AA11689@sun.Sun.COM>
Date: Mon, 29-Dec-86 03:24:26 EST
Article-I.D.: sun.8612290824.AA11689
Posted: Mon Dec 29 03:24:26 1986
Date-Received: Wed, 31-Dec-86 00:37:38 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 31
Approved: tcp-ip@sri-nic.arpa

Path: sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: More NFS discussion
Summary: OK, what *about* "tmpfile"?
Message-ID: <10850@sun.uucp>
Date: 29 Dec 86 08:24:25 GMT
References: <8612242233.AA06278@cbosgd.MIS.OH.ATT.COM>
Sender: news@sun.uucp
Lines: 20

> In all this discussion of ways that NFS doesn't quite meet the
> "UNIX semantics" (this means "UNIX System V semantics", since
> UNIX is a trademark of AT&T and AT&T considers only its own
> releases to be UNIX) there is one more gotcha lurking.
> 
> The traditional implementation of (tmpfile) is to make up a name
> in /tmp, create the file, keep it open, and unlink it.  This works fine
> on System V and 4BSD.  It probably fails on VMS/Eunice.  As far as I'm
> aware, it also fails when /tmp is NFS mounted on a remote system.

Well, you aren't aware of how the Sun NFS implementation works; it works
just fine when "/tmp" is NFS mounted on a remote system.  (I just tried it,
with "tmpfile" - "tmpnam", actually - modified to use an NFS-mounted file
system.)  The local kernel knows that the file is open, and instead of
unlinking it, it renames it to a temporary name and deletes the temporary
file when the last program on the client that created it finishes with it.

Yes, this will fail if a process on a *different* machine unlinks it.
However, it's difficult for another such process to unlink it under UNIX,
since it only has a name for a very short time.