Bug 14997
| Summary: | NFSv3 open O_EXCL fails to set proper "atime" | ||
|---|---|---|---|
| Product: | Base System | Reporter: | wolf <wolf> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 3.3-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->closed 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. |
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. Fix: Painful workaround : we do a "utime" on the file after the successful file creation and before our Sun client uses it. 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.