Weird ext2fs immortal directory bug

Weird ext2fs immortal directory bug

[sentry21]

A long long time ago, I can still remember... My computer hosed itself
(power out as I recall), and then when it was coming back up and running
e2fsck, the power went out again - perhaps not the exact situation, but
suffice to say, init ended up running e2fsck on my drive, and filling
/lost+found/ with lots of garbage, most of which I needed.

I managed to easily clean it out, with one exception. And a friend
recently suggested posting it to this list. Can anyone here
explain what on earth is going on, and how to get rid of it?

Incidentally, it's been around since a custom-compiled 2.3.x (where x > 40
I believe), and has been impervious to my fixing ever since.

Also, I'm not subscribed, so please, any replies CC'ed to
dan@cdslash.net, I'd appreciate it.

Here's the problem(s) (or at least, the symptoms):

sentry21@Petra:1:/lost+found$ ls -l
total 0
lr----S---    1 52       12337           0 Nov  1  2022 #3147 ->

sentry21@Petra:0:/lost+found$ file \#3147/
#3147/: directory

sentry21@Petra:0:/lost+found$ rm -rf \#3147/
rm: cannot unlink `#3147': Permission denied

sentry21@Petra:1:/lost+found$ sudo rm -rf \#3147/
rm: cannot unlink `#3147': Operation not permitted

sentry21@Petra:1:/lost+found$ sudo chown sentry21.sentry21 \#3147/
chown: changing ownership of `#3147': Operation not permitted

sentry21@Petra:1:/lost+found$ cd \#3147/

sentry21@Petra:0:/lost+found/#3147$ ls
#3147@

sentry21@Petra:0:/lost+found/#3147$ cd \#3147/

sentry21@Petra:0:/lost+found/#3147/#3147$ ls
#3147@

sentry21@Petra:0:/lost+found/#3147/#3147$ cd
\#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/

sentry21@Petra:0:/lost+found/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147$ ls
#3147@

sentry21@Petra:0:/lost+found/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147$ pwd
/lost+found/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147

sentry21@Petra:0:/lost+found/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147$ file \#3147/
#3147/: directory


Weird, ne? I -did- manage to make it -not rwxrwxrwx, suid, sgid, sticky,
and every other bloody FS flag you can stick on a directory (and lots you
can't), but it's still impervious to my sk|llz. It's not hurting anything,
but cron whines about it every day.

Thanks.

--Dan

Re: Weird ext2fs immortal directory bug

[Richard B. Johnson]

On Thu, 26 Jul 2001 sentry21@cdslash.net wrote:
[SNIPPED...]
> 
> Here's the problem(s) (or at least, the symptoms):
> 
> sentry21@Petra:1:/lost+found$ ls -l
> total 0
> lr----S---    1 52       12337           0 Nov  1  2022 #3147 ->
> 

Did you try..
# rm -r lost+found
# mklost+found

Without knowing how to use the ext2fs tools, and not wanting to
risk more damage, I tried this and it worked when I had such a
crash-induced problem.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Weird ext2fs immortal directory bug

[sentry21]

> On Thu, 26 Jul 2001 sentry21@cdslash.net wrote:
> [SNIPPED...]
> >
> > Here's the problem(s) (or at least, the symptoms):
> >
> > sentry21@Petra:1:/lost+found$ ls -l
> > total 0
> > lr----S---    1 52       12337           0 Nov  1  2022 #3147 ->
> >
>
> Did you try..
> # rm -r lost+found
> # mklost+found
>
> Without knowing how to use the ext2fs tools, and not wanting to
> risk more damage, I tried this and it worked when I had such a
> crash-induced problem.

sentry21@Petra:1:/$ sudo rm -rf lost+found/
rm: cannot unlink `lost+found/#3147': Operation not permitted
rm: cannot remove directory `lost+found': Directory not empty


Dang.

--Dan

Re: Weird ext2fs immortal directory bug

[Dan Podeanu]

> sentry21@Petra:1:/$ sudo rm -rf lost+found/
> rm: cannot unlink `lost+found/#3147': Operation not permitted
> rm: cannot remove directory `lost+found': Directory not empty
>
>
> Dang.

Perhaps:

debugfs -w <your root filesystem>
unlink /lost+found/#3147

Re: Weird ext2fs immortal directory bug

[Sven Vermeulen]

On Thu, Jul 26, 2001 at 11:04:48AM -0400, sentry21@cdslash.net wrote:
> sentry21@Petra:1:/$ sudo rm -rf lost+found/
> rm: cannot unlink `lost+found/#3147': Operation not permitted
> rm: cannot remove directory `lost+found': Directory not empty

Have you tried "chattr -i \#3147" and then "rm -rf \#3147"? 

-- 
 Sven Vermeulen            -    Key-ID CDBA2FDB 
 LUG: http://www.lugwv.be  -    http://www.keyserver.net

Re: Weird ext2fs immortal directory bug

[sentry21]

> > sentry21@Petra:1:/$ sudo rm -rf lost+found/
> > rm: cannot unlink `lost+found/#3147': Operation not permitted
> > rm: cannot remove directory `lost+found': Directory not empty
>
> Perhaps:
>
> debugfs -w <your root filesystem>
> unlink /lost+found/#3147

root@Petra:0:~# debugfs -w /
debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
/: Is a directory while opening filesystem
debugfs:  ^D

root@Petra:0:~# debugfs -w /dev/hda5
debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
debugfs:  unlink /lost+found/#3147
debugfs:  ^D

root@Petra:0:~# cd /lost+found/

root@Petra:0:/lost+found# ls -l
total 0
lr----S---    1 52       12337           0 Nov  1  2022 #3147 ->
root@Petra:0:/lost+found#

Apparantly I wasn't joking when I said 'immortal'.

--Dan

Re: Weird ext2fs immortal directory bug

[Daniel Phillips]

On Thursday 26 July 2001 16:37, sentry21@cdslash.net wrote:
> sentry21@Petra:1:/lost+found$ cd \#3147/
>
> sentry21@Petra:0:/lost+found/#3147$ ls
> #3147@

It's linked to itself.

--
Daniel

Re: Weird ext2fs immortal directory bug

[Richard B. Johnson]

On Thu, 26 Jul 2001 sentry21@cdslash.net wrote:

> > > sentry21@Petra:1:/$ sudo rm -rf lost+found/
> > > rm: cannot unlink `lost+found/#3147': Operation not permitted
> > > rm: cannot remove directory `lost+found': Directory not empty
> >
> > Perhaps:
> >
> > debugfs -w <your root filesystem>
> > unlink /lost+found/#3147
> 
> root@Petra:0:~# debugfs -w /
> debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> /: Is a directory while opening filesystem
> debugfs:  ^D
> 
> root@Petra:0:~# debugfs -w /dev/hda5
> debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> debugfs:  unlink /lost+found/#3147
> debugfs:  ^D
        ^^^^^^^^
> 
How about 'Q' so debugfs gets to write the modifications to the
drive?


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Weird ext2fs immortal directory bug

[sentry21]

> > root@Petra:0:~# debugfs -w /
> > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > /: Is a directory while opening filesystem
> > debugfs:  ^D
> >
> > root@Petra:0:~# debugfs -w /dev/hda5
> > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > debugfs:  unlink /lost+found/#3147
> > debugfs:  ^D
>         ^^^^^^^^
> How about 'Q' so debugfs gets to write the modifications to the
> drive?

root@Petra:0:/lost+found# debugfs -w /dev/hda5
debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
debugfs:  unlink /lost+found/#3147
unlink_file_by_name: No free space in the directory


This is getting weirder and weirder.


--Dan

Re: Weird ext2fs immortal directory bug

[Wayne.Brown]

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.

Wayne




sentry21@cdslash.net on 07/26/2001 10:04:48 AM

To:   "Richard B. Johnson" <root@chaos.analogic.com>
cc:   linux-kernel@vger.kernel.org (bcc: Wayne Brown/Corporate/Altec)

Subject:  Re: Weird ext2fs immortal directory bug



> On Thu, 26 Jul 2001 sentry21@cdslash.net wrote:
> [SNIPPED...]
> >
> > Here's the problem(s) (or at least, the symptoms):
> >
> > sentry21@Petra:1:/lost+found$ ls -l
> > total 0
> > lr----S---    1 52       12337           0 Nov  1  2022 #3147 ->
> >
>
> Did you try..
> # rm -r lost+found
> # mklost+found
>
> Without knowing how to use the ext2fs tools, and not wanting to
> risk more damage, I tried this and it worked when I had such a
> crash-induced problem.

sentry21@Petra:1:/$ sudo rm -rf lost+found/
rm: cannot unlink `lost+found/#3147': Operation not permitted
rm: cannot remove directory `lost+found': Directory not empty


Dang.

--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/

Re: Weird ext2fs immortal directory bug

[Richard B. Johnson]

On Thu, 26 Jul 2001 sentry21@cdslash.net wrote:

> > > root@Petra:0:~# debugfs -w /
> > > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > > /: Is a directory while opening filesystem
> > > debugfs:  ^D
> > >
> > > root@Petra:0:~# debugfs -w /dev/hda5
> > > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > > debugfs:  unlink /lost+found/#3147
> > > debugfs:  ^D
> >         ^^^^^^^^
> > How about 'Q' so debugfs gets to write the modifications to the
> > drive?
> 
> root@Petra:0:/lost+found# debugfs -w /dev/hda5
> debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> debugfs:  unlink /lost+found/#3147
> unlink_file_by_name: No free space in the directory
> 
> 
> This is getting weirder and weirder.
> 
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".



Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Weird ext2fs immortal directory bug

[Horst von Brand]

<sentry21@cdslash.net> said:
> > > root@Petra:0:~# debugfs -w /
> > > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > > /: Is a directory while opening filesystem
> > > debugfs:  ^D
> > >
> > > root@Petra:0:~# debugfs -w /dev/hda5
> > > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > > debugfs:  unlink /lost+found/#3147
> > > debugfs:  ^D
> >         ^^^^^^^^
> > How about 'Q' so debugfs gets to write the modifications to the
> > drive?
> 
> root@Petra:0:/lost+found# debugfs -w /dev/hda5
> debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> debugfs:  unlink /lost+found/#3147
> unlink_file_by_name: No free space in the directory

What machine is that? e2fsprogs-1.22 had some similar weird effects on
SPARC with kernel 2.4.x, 1.20 works fine AFAICS.

You can try nuking the directory (clear_inode or such) and have fsck(8)
pick up the resulting fallout.
-- 
Dr. Horst H. von Brand                Usuario #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Weird ext2fs immortal directory bug

[Andreas Dilger]

Dan writes:
> sentry21@Petra:1:/lost+found$ sudo rm -rf \#3147/
> rm: cannot unlink `#3147': Operation not permitted
> 
> Weird, ne? I -did- manage to make it -not rwxrwxrwx, suid, sgid, sticky,
> and every other bloody FS flag you can stick on a directory (and lots you
> can't), but it's still impervious to my sk|llz. It's not hurting anything,
> but cron whines about it every day.

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

Cheers, Andreas
-- 
Andreas Dilger                               Turbolinux filesystem development
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: Weird ext2fs immortal directory bug

[Richard B. Johnson]

On Thu, 26 Jul 2001 Wayne.Brown@altec.com wrote:

> 
> 
> 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.
> 
> Wayne

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.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.