From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1L3KdU-0004Mh-7b for garchives@archives.gentoo.org; Fri, 21 Nov 2008 01:16:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0D874E053C; Fri, 21 Nov 2008 01:16:38 +0000 (UTC) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by pigeon.gentoo.org (Postfix) with ESMTP id BFB11E053C for ; Fri, 21 Nov 2008 01:16:37 +0000 (UTC) Received: by fk-out-0910.google.com with SMTP id 18so851066fks.2 for ; Thu, 20 Nov 2008 17:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=w02rXp+TbwE0xWYTvnX61lrkQRy+yOeEgreSt7Og/mM=; b=plaWOD9tVITsOD5+kkBJKGH8uAkkN8BhodSxIXnQpibg0ULdqn9ItVQLr6l0+N78iD 78U1A1eAEuICprYZxQmpusqNOpTi70Z0p08weB2CdqOg7sEvEOx+DrPG3awbCqtjRCw3 Ue26RGRnD0mBBFWYG/v3+e2KEqdcnWrGQTGnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=nenFCUQFcbUhqhP8ZbeQAThmZn17B2a/9WRQ3rdXzBseqVwCEd5LEuFm+y6xCUdIhZ bN1JWVbrJvFDRD/7XnHK27Y8c2xyVRexHb7WKhdIR5J1cltU9TpU0wWurb38FNMxvtEQ dGLBOi+vAFUwa/KICPHYseh9/Xxr1uG9Zvtkk= Received: by 10.103.172.9 with SMTP id z9mr979583muo.109.1227230195472; Thu, 20 Nov 2008 17:16:35 -0800 (PST) Received: by 10.103.168.9 with HTTP; Thu, 20 Nov 2008 17:16:35 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 20:16:35 -0500 From: "Andrey Vul" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] forcing file removal, fails with ESTALE In-Reply-To: <4925FD9D.4070608@netspace.net.au> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4925FD9D.4070608@netspace.net.au> X-Archives-Salt: 1e1f9332-d058-42d4-9ce3-6b988d9cd00a X-Archives-Hash: d3d2f8b8478a625403bb47af33c499e8 On Thu, Nov 20, 2008 at 19:15, Iain Buchanan wrote: > Qian Qiao wrote: >> >> On Thu, Nov 20, 2008 at 18:13, Andrey Vul wrote: >>> >>> I'm trying to remove a file, yet it fails with ESTALE ("Stale NFS file >>> handle"). I'm thinking that this is due to a corrupt inode but fsck >>> fails to fix it. >>> >>> Is /lib/rc/console/unicode suppoed to be NFS or do I need to do a long >>> hard fsck of /? >>> -- >>> Andrey Vul >>> >>> A: Because it messes up the order in which people normally read text. >>> Q: Why is top-posting such a bad thing? >>> A: Top-posting. >>> Q: What is the most annoying thing in e-mail? >> >> It's just a stale handle, i.e., some process opened the file, but the >> file is then deleted, moved or renamed by another process. >> >> If you know what process is holding the handle of the non-existent >> file, restart it, if not, re-mount the file system. > > `umount -l` might help you there. Umount -l fixes inconsistent inodes / directory entries? I thought only fsck -f could do that. Anyways, I rebooted into bb (init=/bin/bb) and ran /sbin/jfs_fsck -f /dev/root . That fixed the stale file handle. You know it's fsck -f time when dmesg has "jfs_lookup: cannot read #####" lines.