* Example issues with NFS v2/v3

In Unix you can do this:

open()
read()
write()
read()
write()
close()

If try to read/write file after close, will get an error b/c fd is invalid.


open()
read()
write()
unlink() // yes, can unlink an open'ed file
read() // this'll succeed, b/c fd is still open!
write() // also succeed
close() // on close, the actual inode will be removed from disk

* In NFS v2/v3

SYSCALL	NFS CLIENT MSG
------------------------------
open		NFS_GETATTR (server has no idea that the client open'ed a file)
read		NFS_READ
write		NFS_WRITE
close		nothing (server doesn't know how long it should "cache" anything)

SYSCALL	NFS CLIENT MSG
------------------------------
open		NFS_GETATTR (server has no idea that the client open'ed a file)
read		NFS_READ
unlink		NFS_REMOVE (server removes file, and inode/data)
write		NFS_WRITE (server can't find file, returns ESTALE)
close		nothing (server doesn't know how long it should "cache" anything)

Result: statelessness of protocol broke POSIX semantics!

Note: the client issuing syscalls knows that the unlink is happening on an
opened file.

SYSCALL	NFS CLIENT MSG
------------------------------
open		NFS_GETATTR (server has no idea that the client open'ed a file)
read		NFS_READ
unlink		NFS_RENAME (rename file X to some other name Y)
write		NFS_WRITE (succeeds b/c file inode + data are still on server)
close		NFS_REMOVE of file 'Y' (server actually deleting file)

The renaming scheme took any file, and renamed it to a "hidden" file called
.nfsXXXXXX where XXXXXX is some random number.

Over time, if clients crash, some of these .nfsXXXXXX files linger around.
Admins had to look for leftover .nfs files and purge them iff they
determined not to be used by anyone.