Thorsten Frueauf writes:
> Last night I had some strange problem that messed my disk totaly up :-(

ouch :(

> On my Laptop (Toshiba Tecra 500 CDT, running NetBSD/i386 current from
> 19.09.97) there is an external modem (Creatix SG 2834) connected.  I
> freshly booted, started X (Xfree86 3.3.1) and wanted to logon to my
> ISP via ppp.  modem - it has an external power supply - seemed not to
> react, so I waited until pppd timed out, stoped my script, and
> powercycled the modem.  Thats were my Laptop froze up - no
> keyboard/mouse reaction anymore, even CTRL-ALT-DEL did not work.  So I
> had to powercycle the Laptop too.  So far so good - this happend some
> times before (although I found it strange that this can lock up the
> machine - on my amiga this does not happen at all).  I rebooted to
> single user mode to do an fsck.  And there the nightmare begun :-(
 
> fsck detected many things it suggested to fix, so I decided to
> do an fsck -y (maybe that was my fault no. 2). After that lots of files
> and directories are now in lost+found (and thus disappeard from there
> former location) :-(

as an aside; i *never* do fsck -y unless i've already run fsck and
gotten a) inundated with a lot of 'answer y to fix' questions, and
b) know i've got a usuable backup anyway...


> So now I have some questions:
> 
> 1) Is it possible that recent changes to fsck_ffs (lite 2 integration) messed
>    something up? I had those lock ups before, but fsck was always able
>    to clean it up properly.

possibly, but hopefully not. I've just checked the source for fsck and
fsck_ffs again, and besides the changes which were rcsid or
stylistically related, there were only a few minor changes to fsck_ffs:
	pass2.c:121: sets statemap[ROOTINO] = DFOUND;
	pass2.c:160: sets dp->di_size differently
	pass2.c:439: new case entry for DSTATE
	setup.c:449: copies sblock.fs_unused_1 -> altsblock.fs_unused_1
	utilities.c:290: save & restore fsmodified around flush() call
	utilities.c:293: print a message if !preen
hopefully an FS guru can help us here:

the mods in pass2.c are the largest changes, and whilst I don't think
they'd cause a problem, you never know... also, maybe fs_unused_1 has
some significance, but I couldn't see any reference to it in /sys/ufs/*
(besides its definition)


> 2) How does one handle those many files/directories in lost+found? If it
>    were only a few, I would moved them by hand... but this are _many_.
>    I started to identify the files (all names #<inode number>) and tryed
>    to move them back to there proper position - but fsck reports those
>    files to be a problem (something like EXTENTIOS link) and moves them
>    back into lost+found again :-(( What is the proper way to clean this
>    up?

by hand.


> 3) I noticed that the directory inode, where a file is missing and moved
>    into lost+found, has stil an entry, but the inode is set to 0.
> 
>    e.g. I had a directory /usr/export/frueauf/texte/Steuer/
>    in /usr/lost+found I found #000439 which seemed to be that directory.
>    If I look with fsdb at /usr/export/frueauf/texte I find stil
>    "Steuer" in a slot, but with inode 0. ls -la in that directory
>    does *not* show it. After I moved /usr/lost+found/#000439 to
>    /usr/export/frueauf/texte/Steuer I see 2 entrys for "Steuer" in
>    /usr/export/frueauf/texte with fsdb :-( I think this is the case
>    with all files that made it into lost+found - how does one
>    fix this?

maybe one is a deleted directory entry? i don't know :(


> So I would be happy for anyone that can help me fixing this. As always
> in such situations the last backup is 1-2 months ago, so I can not
> simply newfs and restore. I would prefer to somehow relocate those
> files in lost+found to there former place. I really don't know how
> this is properly done.

> PS: If I need to provide more infos - feel free to ask.

/usr wasn't mounted at the time, was it? from your message I don't
think it was.

would a copy of fsck_ffs prior to the changes help?