Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!gatech!purdue!decwrl!sun!pugsley!silveri
From: silveri%pugsley@Sun.COM (Chris Silveri)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS "null block" bug encountered + FIX
Summary: NFS Non-idempotent Procedures
Keywords: NFS null zero
Message-ID: <72418@sun.uucp>
Date: 11 Oct 88 06:21:08 GMT
References: <7376@bloom-beacon.MIT.EDU>
Sender: news@sun.uucp
Lines: 37

In article <7376@bloom-beacon.MIT.EDU>, jtkohl@athena.mit.edu (John T Kohl) writes:
> At MIT Project Athena, we have been bitten hard by a problem in the 3.0
> (and 3.2) NFSSRC (VAX and IBM/RT 4.3BSD UNIX) handling of non-idempotent
> requests, such as create-with-truncate.  This particular bug evidenced
> itself by creating "holes" in files and unexpectedly truncating files
> with no error indicated to the client user-level code.
> 
> Our fix is to send the last known modification time in the truncation
> request to the NFS server.  When the server sees a truncation request
> with a valid modification time, it checks this time against the time
> stored in the filesystem inode.  If they match, the truncation is
> performed, otherwise the packet is treated as a duplicate.

NFS version 3 addresses the problem of SETATTR as well as the other
non-idempotent procedures. Clients will have to supply a correct
"ctime" to the server. If the "ctime" does not match, the server returns
a duplicate request error. 

Other changes include the addition of an exclusive flag to 
CREATE, and fhandles of targets to destroy in non-exclusive 
CREATEs, REMOVES, etc.

And much more...


The protocol specification for NFS version 3 is in public domain
and has been circulated at several conferences (e.g. Usenix in S.F).
We welcome your comments and suggestions about the spec. A special
mail alias has been setup {sun!nfs3 or nfs3@sun.com} to receive them.


*** NOTE *** Currently all NFS implementations use version 2 
of the NFS protocol !!!



Christopher Silveri		Sun Microsystems