]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
If the effective link count is zero when an NFS file handle request
authormckusick <mckusick@FreeBSD.org>
Sun, 13 May 2001 23:30:45 +0000 (23:30 +0000)
committermckusick <mckusick@FreeBSD.org>
Sun, 13 May 2001 23:30:45 +0000 (23:30 +0000)
commit0c59ac9908d993e25fc48b2659808ce946a74fee
tree3520c82a7abbf9e02f34312d7fde9b0a99f24f4d
parenta7c1f8c826caae6a2c73f9168cddd6e1b25f1b21
If the effective link count is zero when an NFS file handle request
comes in for it, the file is really gone, so return ESTALE.

The problem arises when the last reference to an FFS file is
released because soft-updates may delay the actual freeing of the
inode for some time. Since there are no filesystem links or open
file descriptors referencing the inode, from the point of view of
the system, the file is inaccessible. However, if the filesystem
is NFS exported, then the remote client can still access the inode
via ufs_fhtovp() until the inode really goes away. To prevent this
anomoly, it is necessary to begin returning ESTALE at the same time
that the file ceases to be accessible to the local filesystem.

Obtained from: Ian Dowse <iedowse@maths.tcd.ie>
sys/ufs/ufs/ufs_vfsops.c