In order to avoid flooding the list and everyone else with replies to all
the e-mails I've recieved, I'm going to put them all in one. Hope this
doesn't cause anyone problems.
One of the suggestions -did- work, but I thought I should post replies to
the rest of the suggestions where possible, so that people know what
worked and what didn't.
Here's the summary:
---->From Daniel Phillips <phillips@bonn-fries.net>:
> > sentry21@Petra:1:/lost+found$ cd \#3147/ > > > > sentry21@Petra:0:/lost+found/#3147$ ls > > #3147@ > > It's linked to itself.
Yes, it's a directory as well as a symlink to itself. It, quite frankly, should not exist. Go figure.
----
>From Christopher Allen Wing <wingc@engin.umich.edu>:
> You can remove it using the 'debugfs' program. The safest way to do this > is to boot your machine to single user mode, and then do: > > mount -o remount,rw / > sync > debugfs -w /dev/device_that_/_is_mounted_on > > then at the debugfs: prompt > > cd /lost+found > rm #3147 > close > quit > > > Then: > sync > reboot > > and it should be gone.
This worked admirably, my thanks.
----
>From Wayne.Brown@altec.com:
> Try lsattr ./#3147 and see if the i attribute is set. If so, then (as > root) do chattr -i ./#3147 and try again to remove it.
I tried this, after doing 'chattr -AacdijsSu ./#3147' (which did not help), and tried removing after both, which did not work.
----
>From Richard B. Johnson <root@chaos.analogic.com>:
> Okay, the file is a link, linked to /lost+found. So, using debugfs, > just remove the directory: > # debugfs -w /dev/hda5 > debugfs: rmdir /lost+found > > My debugfs is too old, so the above command replies with "Unimplemented".
As did mine - the version in Debian Unstable, which I assume is the latest (debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09).
----
>From Horst von Brand <vonbrand@inf.utfsm.cl>:
> What machine is that? e2fsprogs-1.22 had some similar weird effects on > SPARC with kernel 2.4.x, 1.20 works fine AFAICS.
i386, pretty standard boring stuff.
> You can try nuking the directory (clear_inode or such) and have fsck(8) > pick up the resulting fallout.
This was going to be my next step, if the suggestion that worked hadn't.
----
>From Andreas Dilger <adilger@turbolinux.com>:
> Run "debugfs -w /dev/hdX", and then: > > debugfs> mi <3147> > # set Mode to 0 > # set Deletion time to something other than 0 > # set Link count to 0 > # set Block count to 0 > # set File flags to 0 > debugfs> freei <3147> > debugfs> q > > e2fsck -f /dev/hdX
e2fsck complained about the file not being attached, and attached it to lost+found - basically, the exact same thing that happened in the first place. Go figure. Suffice to say, this also did not work.
----
>From Richard B. Johnson <root@chaos.analogic.com>:
> If you try that from a shell, it may fail because '#' means > "ignore everything thereafter", so you are trying to do muck > with the directory. I think: > > chattr -i ./\#3147 had ought to do it.
bash (and likely others) will figure out that #filename is a directory if the # is part of a string blah#blah, and will only treat it as a comment if there is a space in front of it.
----
Thank you all for your help and efforts in solving this extremely peculiar bug. I still have no idea why it happened, but now that it's gone, cron should rest happily at night.
Cheers.
--Dan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:28 EST