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.

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

[sentry21]

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

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

[Christopher Allen Wing]

I am assuming that the problem here was that fsck restored a lost inode to
lost+found, but the inode had been corrupted and had the immutable bit
set.

It should be pointed out that there is currently no way to modify ext2
attributes for symlinks or device files, because ext2 attributes are
implemented via an ext2-specific ioctl(). You can't open() symlinks to
even attempt an ioctl, and ioctl on a device file goes directly to the
device, skipping ext2's ioctl method.

So, in the long term do we need some sort of lchflags() system call to
operate on names?

At the very least, ext2 fsck should complain about ext2 attributes set for
symlinks or device files... I have had this same problem myself many times
on machines with bad SCSI termination- I end up with unremovable device
files thanks to a bogus immutable bit and have to use debugfs to get rid
of them.

-Chris Wing
wingc@engin.umich.edu


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

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

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

[Alan Cox]

> I am assuming that the problem here was that fsck restored a lost inode to
> lost+found, but the inode had been corrupted and had the immutable bit
> set.

Which would actually be an fsck bug, since such an inode isnt legal and cant
be fixed by normal means
 

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

[Andreas Dilger]

Chris Wing writes:
> I am assuming that the problem here was that fsck restored a lost inode to
> lost+found, but the inode had been corrupted and had the immutable bit
> set.
> 
> At the very least, ext2 fsck should complain about ext2 attributes set for
> symlinks or device files... I have had this same problem myself many times
> on machines with bad SCSI termination- I end up with unremovable device
> files thanks to a bogus immutable bit and have to use debugfs to get rid
> of them.

It should actually assume that such inodes are corrupt, and either just
delete them at e2fsck time, or at least clear the "bad" parts of the inode
before sticking it in lost+found.

Cheers, Andreas

PS - I CC'd Ted on this, as he can probably fix this a lot faster than I
     (I may be able to fix it during another OLS presentation today or
     tomorrow).
-- 
Andreas Dilger                               Turbolinux filesystem development
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

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

[Chris Meadors]

On Thu, 26 Jul 2001, Andreas Dilger wrote:

> It should actually assume that such inodes are corrupt, and either just
> delete them at e2fsck time, or at least clear the "bad" parts of the inode
> before sticking it in lost+found.

I had this happen to me once before.  I did something bad, and when I
started my machine up again, I got a couple of files in lost+found.  I
couldn't delete two of them.

I posted my trouble here, and I got many of the same hints I've seen given
this time around.

What just made me think, is you just said that e2fsck should clean up this
problem before putting it in lost+found.  That is probally a good idea.
But it was also half way to my solution.  e2fsck did know there was
something wrong with the inodes, but since it marked the disk clean the
first time it was run it wouldn't bother looking over the disk upon
farther reboots.  I wasn't comfortable with figuring out how to use
debugfs, so I just left the 2 bad files there.  Until I did something
else silly and another fsck was forced.  Upon being run the second time
e2fsck did notice something out of order and fixed up the files so I could
delete them.

So yes, e2fsck probally should have noticed the problem the first time
through and not written a funky file to lost+found.  But this might be a
possible solution for the orginal poster of the message.  Just force a
check right now and see if it gets fixed.

-Chris
-- 
Two penguins were walking on an iceberg.  The first penguin said to the
second, "you look like you are wearing a tuxedo."  The second penguin
said, "I might be..."                         --David Lynch, Twin Peaks

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

[Andreas Dilger]

Chris Wing writes:
> At the very least, ext2 fsck should complain about ext2 attributes set for
> symlinks or device files... I have had this same problem myself many times
> on machines with bad SCSI termination- I end up with unremovable device
> files thanks to a bogus immutable bit and have to use debugfs to get rid
> of them.

I checked, and at least recent versions of e2fsck complain/fix immutable
flags on device files, fifos, and sockets.  The below check disallows
immutable or append-only flags on symlinks (on the grounds that it is not
possible to set these legally).

Now what I need to do is also add an e2fsck test case for this...

Cheers, Andreas
===========================================================================
--- 1.56/e2fsck/pass1.c	Thu Jul 19 14:31:24 2001
+++ edited/e2fsck/pass1.c	Thu Jul 26 16:18:59 2001
@@ -559,6 +563,7 @@
 			check_size(ctx, &pctx);
 			ctx->fs_blockdev_count++;
 		} else if (LINUX_S_ISLNK (inode.i_mode)) {
+			check_immutable(ctx, &pctx);
 			ctx->fs_symlinks_count++;
 			if (!inode.i_blocks) {
 				if (inode.i_size_high ||

-- 
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

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

[Gerhard Mack]

It should probably not allow things to be both a directory and a symlink
as well.  I asked the original poster and he indicated the permissions
were "all on" when he first discovered the file. Clearly that's not
a combination fsck should let pass.

 
	Gerhard
 

On Thu, 26 Jul 2001, Andreas Dilger wrote:

> Chris Wing writes:
> > I am assuming that the problem here was that fsck restored a lost inode to
> > lost+found, but the inode had been corrupted and had the immutable bit
> > set.
> > 
> > At the very least, ext2 fsck should complain about ext2 attributes set for
> > symlinks or device files... I have had this same problem myself many times
> > on machines with bad SCSI termination- I end up with unremovable device
> > files thanks to a bogus immutable bit and have to use debugfs to get rid
> > of them.
> 
> It should actually assume that such inodes are corrupt, and either just
> delete them at e2fsck time, or at least clear the "bad" parts of the inode
> before sticking it in lost+found.
> 
> Cheers, Andreas
> 
> PS - I CC'd Ted on this, as he can probably fix this a lot faster than I
>      (I may be able to fix it during another OLS presentation today or
>      tomorrow).
> -- 
> Andreas Dilger                               Turbolinux filesystem development
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> -
> 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/
> 

--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.