>> Yes, but why does that mean it "has to be" cleared?  I can't see any
>> harm that would come from relinking it.
> It's already hard to recover data from /lost+found when something got
> wrong; adding deleted files will make more files to sort and won't
> help - especially if you have to determine the last version of the
> file.

As I think someone else already said, this won't catch all deleted
files, only those that still exist as inodes but just have no directory
entries pointing to them (ie, those that were still open at the point
of failure).

>> at least optionally (ie, as an option to fsck_ffs).
> optionally is't OK with me

I'm not sure whether that's a typo for "isn't" or for "it's".  Based on
general context I assume it's the latter.

I've now done the tweaks to fsck_ffs; I added -z which tells it that
when it finds a file with zero link count but non-zero size, it should
link it into lost+found instead of torching it.  The changes seem to
work in my tests, but of course the only way to tell for sure is to try
them "live".  They're part of my private patch tree and can therefore
be found on ftp.netbsd.org; specifically, in

ftp.netbsd.org:/pub/NetBSD/misc/mouse/patch-tree/src/sbin/fsck_ffs/

though you probably should be careful in applying them; there is one
unrelated change in main.c which makes "skipclean" default to 0 instead
of 1.  You may want to edit that out of the patch file before applying
it, or undo it by hand.  And of course if you're applying them to
-current the line numbers are liable to be wrong.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B