Re: Weird ext2fs immortal directory bug (all-in-one)

[<sentry21@cdslash.net>]

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