[like the other two messages, I won't be able to reply for a long time]


Moin,

I accidentally ran NetBSD-current's fsck_ext2fs (from source a few
months ago now) on an unclean Linux ext2fs filesystem.  The result
was not pretty, and I couldn't fix it quickly with the native Linux
e2fsck, so I simply newfs-ed the whole thing.

(I believe the filesystem had been mounted rw under Linux, when a
power outage occurred, and I rebooted into NetBSD-current, which
ran the fsck_ext2fs at boot on the unclean filesystem, so the hacks
I mentioned in earlier messages are probably irrelevant here.)

I haven't looked at all at the code to see what might be at fault.
As I note, the range of inode numbers used in ext2fs differs by one
from that in most other ufs filesystems -- perhaps this is the
problem, where the wrong inodes numbers are referred to in the fsck
code.  Or it could be something else.

If someone wants to look at this, please do so -- you'll likely
be able to fix it before I go online, even if I find the problem
tomorrow.

This can probably be reproduced by force-fsck_ext2fs'ing a Linux
filesystem with something on it under NetBSD-current, and then
running the native Linux e2fsck to see what it thinks, but I have
tried nothing since having the problem.


thanks
barry bouwsma