From nobody@FreeBSD.ORG Fri Nov 19 10:30:10 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 9772E14C88; Fri, 19 Nov 1999 10:30:10 -0800 (PST)
Message-Id: <19991119183010.9772E14C88@hub.freebsd.org>
Date: Fri, 19 Nov 1999 10:30:10 -0800 (PST)
From: wolf@oleane.net
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: NFSv3 open O_EXCL fails to set proper "atime"
X-Send-Pr-Version: www-1.0

>Number:         14997
>Category:       kern
>Synopsis:       NFSv3 open O_EXCL fails to set proper "atime"
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 19 10:40:00 PST 1999
>Closed-Date:    Thu Jan 4 23:11:46 PST 2001
>Last-Modified:  Thu Jan 04 23:16:39 PST 2001
>Originator:     Christophe Wolfhugel
>Release:        3.3-RELEASE
>Organization:
France Telecom Oleane
>Environment:
FreeBSD smtp1.cluster.oleane.net 3.3-RELEASE FreeBSD 3.3-RELEASE #2: Mon Oct 11 17:51:19 GMT 1999     root@:/usr/src/sys/compile/SMTP.CLUSTER  i386
>Description:
NFS server = Netapp hardware. We do create a file over NFS using
following : open("toto", O_WRONLY|O_CREAT|O_EXCL, 0644) and then
close the file. We after that switch to a Sun Solaris client which
will fail to "stat" the file. Using "snoop" it happens that the "getattr"
returns an atime value which looks like uninitialized memory :

NFS:    Last access time      = -1021768688.-1679294464
NFS:    Modification time     = 19-Nov-99 17:51:27.960000000 GMT
NFS:    Attribute change time = 19-Nov-99 17:51:27.960000000 GMT

The FreeBSD client does not grok probably because it does less checks
on the atime. A tcpdump on the FreeBSD side for the same stat call
gives :
19:27:33.564961 192.168.1.201.2049 > 192.168.1.1.2051613514: reply ok 120
 
access attr: REG 644 ids 0/0 sz 5 nlink 1 rdev 0/0 fsid 0 nodeid 0
a/m/ctime 3273198608.1407713280 943035960.650001000 943035960.650001000
 c 002d (ttl 64, id 45316)

That clearly shows that the atime value is somewhat strange. When not
using O_EXCL the problem is not there.
>How-To-Repeat:
open O_EXCL the file, close it, stat it. We have not tested with a
different NFSserver, so that can either be a FreeBSD or a Netapp issue.
>Fix:
Painful workaround : we do a "utime" on the file after the successful
file creation and before our Sun client uses it.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: dillon 
State-Changed-When: Thu Jan 4 23:11:46 PST 2001 
State-Changed-Why:  

The NFSv3 access time screwup for O_EXCL opens has been fixed in 
-current (5.x), and will be MFC'd to -stable (4.x) on friday 
Jan 5 2001.  I will look into MFCing it to 3.x... I'll do it if 
it is trivial. 

The NFSv3 protocol uses the time fields to store the file verifier. 
The client is supposed to do a SETATTR after a successful O_EXCL open to 
clean it up. The FreeBSD client code was not doing the correct SETATTR, 
leaving the file attributes in a broken state. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=14997 
>Unformatted:
