> I was part of the discussion group for NFSv4 spec
> the short comings of v2 and v3 have been fixed
I'm a bit surprised by this. Which "discussion group"?
> NFSD (v2/v3) is stateless other than the information provided by
> mountd (mount requests) and lockd (file locking).
NFS is stateless save the state information remembered by statd. After all,
that's the whole point of statd (and the NLM grace period).
> A long time ago FileSystemHandle would stay the same between reboots
> and you wouldn't get this problem other than on an individual file.
My XNFS says:
> 7.1.3 Stateless Servers and Idempotency
[...]
> With a few exceptions, rebooting the server must not invalidate
> distributed state information.
(with the exceptions being unstable writes, teporary files etc.)
> To handle deleted files which are in use by NFS clients some servers
> rename them to .nfs* because if one client deleted and other clients
> where accessing the file then they would get Stale NFS handle.
This rename takes place on the client on a REMOVE, not on the server.
Cf. either McKusick et. al. or RFC 1813, 3.3.12, IMPLEMENTATION.
> Once in a while a NFS server will do find $dir -type f -name .nfs\*
> -mtime +7 -mount -exec rm -f {} \; to clean up.
Do you have any reference for that?
> If you do not get the Stale File Handle error when the server
> reboots, it most likely means the FileSystemHandle is not changing
> between reboots
I.e., it conforms to the specs.
> but then you may have more security issues.
Could you please elaborate on this "secutity issues"?
