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.