From owner-cvs-all  Sun May 13 16:30:49 2001
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 186A137B423; Sun, 13 May 2001 16:30:46 -0700 (PDT)
	(envelope-from mckusick@FreeBSD.org)
Received: (from mckusick@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f4DNUkB97827;
	Sun, 13 May 2001 16:30:46 -0700 (PDT)
	(envelope-from mckusick)
Message-Id: <200105132330.f4DNUkB97827@freefall.freebsd.org>
From: Kirk McKusick <mckusick@FreeBSD.org>
Date: Sun, 13 May 2001 16:30:45 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/ufs/ufs ufs_vfsops.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

mckusick    2001/05/13 16:30:45 PDT

  Modified files:
    sys/ufs/ufs          ufs_vfsops.c 
  Log:
  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>
  
  Revision  Changes    Path
  1.25      +4 -2      src/sys/ufs/ufs/ufs_vfsops.c


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message