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
	#include 
	FILE *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