From owner-freebsd-current Sat Oct 11 15:06:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13263 for current-outgoing; Sat, 11 Oct 1997 15:06:14 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13235 for ; Sat, 11 Oct 1997 15:06:06 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA06146; Sat, 11 Oct 1997 15:05:51 -0700 (MST) From: Terry Lambert Message-Id: <199710112205.PAA06146@usr06.primenet.com> Subject: Re: make world failed To: helbig@Informatik.BA-Stuttgart.DE (Wolfgang Helbig) Date: Sat, 11 Oct 1997 22:05:51 +0000 (GMT) Cc: bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199710110903.LAA02400@rvc1.informatik.ba-stuttgart.de> from "Wolfgang Helbig" at Oct 11, 97 11:03:59 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > failure occurs early, for rm -f, because nfs returns ESTALE instead > > of ENOENT for (necessarily) failing lookups in the removed directory, > > and rm -f doesn't understand ESTALE. > > Should it? No. A local name cache hit that gets a vnode that references an nfsnode with a no longer valid verifier, generation count, or inode on the target system requires a return of ESTALE. One might better ask if the name cache code should be referenced on an NFS client without some kind of distributed cache coherency protocol; but this particular failure mode is not what is happening to you. Your failure is a real bug cause by a name cache deletion being omitted. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.