Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!cbosgd.mis.oh.att.com!mark From: mark@cbosgd.mis.oh.att.com.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: More NFS discussion Message-ID: <8612242233.AA06278@cbosgd.MIS.OH.ATT.COM> Date: Wed, 24-Dec-86 17:33:00 EST Article-I.D.: cbosgd.8612242233.AA06278 Posted: Wed Dec 24 17:33:00 1986 Date-Received: Thu, 25-Dec-86 00:35:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa Summary: what about tmpfile? 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. ANSI X3J11 C has a required function called tmpfile(). This function takes no arguments, and is defined in the 10/86 draft section 4.9.4.3 thus: Synopsis #includeFILE *tmpfile(void); Description The tmpfile function creates a temporary binary file that will automatically be removed when it is closed or at program termination. The file is opened for update. Returns The tmpfile function returns a pointer to the stream of the file that is created. If the file cannot be created, the tmpfile function returns a null pointer. The traditional implementation of this function 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. Given the stateless nature of NFS, is there a way to upgrade it to support tmpfile? If not, it's going to be awfully hard to conform to ANSI C in an NFS environment. Mark Horton