Re: [gentoo-user] forcing file removal, fails with ESTALE

["Andrey Vul" <andrey.vul@gmail.com>]

On Thu, Nov 20, 2008 at 19:15, Iain Buchanan <iaindb@netspace.net.au> wrote:
> Qian Qiao wrote:
>>
>> On Thu, Nov 20, 2008 at 18:13, Andrey Vul<andrey.vul@gmail.com>  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.