SUMMARY: SCO Unix loses lost+found

[Bernd Felsche]

In <1991Jun23.065836.15692 at metapro.DIALix.oz.au> I wrote:

>Has anybody else noticed the occasional loss of /lost+found under SCO Unix?

>There are only two people who can remove the thing, and we haven't.

>Any clues?

>(I'm running a cron task to check for lost+found on all
>mounted file systems at 3 hour intervals, to make sure we
>have somewhere to put lost files in case of a crash)

I have received responses from:
 Roger Cornelius <rac at sherpa.UUCP>
 Pat Myrto <pat at rwing>
 Judy Scheltema <judy at lobster.hou.tx.us>
 Ted Chan <ys2!twc at murtoa.cs.mu.oz.au>
 Jay Vassos-Libove <libove at libove.det.dec.com>

Many thanks for your interest and clues. The first item contains the
most extensive solution.

Here's the summary:

From: Roger Corneliussherpa!rac <sherpa!rac%murtoa.cs.mu.oz at uunet.uu.net>

If you're using 3.2.0, there was a bug in the /etc/cleanup script
which did this.  It has been fixed in 3.2.2.  I no longer have a copy
of the script that had the problem, but look for the find which
searches through lost+found.  If I remember correctly, it was something
like:

	find /lost+found -mtime +21 -exec rm -rf {} \; >/dev/null 2>&1

Notice the rm -rf.
The following is the code I replaced it with.  The important thing
is to get rid of the -r option to rm.

# clean up all mounted lost+found directories
filesystems=`/etc/mount|sed 's/[ 	].*//'`
for mount in filesystems
do
	find $mount/lost+found -mtime +21 -exec rm -f {} \; >/dev/null 2>&1
done

--------------- 

From: rwing!pat <rwing!pat%murtoa.cs.mu.oz at uunet.uu.net>

I don't run SCO, but ISC, and I had a similar problem.  The cause was
root via cron is removing it, via a line in /etc/cleanup, that goes
something like

find /lost+found +mtime +14 -exec rm -rf {} \;

Note the 'r' in the rm command, meant to clean up any subdirs put in
lost+found.  Unfortunately, it also removes /lost+found.  A check for
existance of lost+found should be done, then a cd to it, then do a
find on the current subdir, or safer yet, remove the r from the rm
command, and check it yourself periodially.  Note the test for
lost+found is CRITICAL if you use the cd to lost+found option and keep
the 'r' in the rm command, else if the cd ails, the rm -rf will be
running on the *root* subdir, thus wiping out the WHOLE FILESYSTEM.

So, to be safe, I just changed mine to be

find /lost+found +mtime +14 -exec rm -f {} \;
                            no 'r' ---^
and will deal with reconnected subdirs manually.  Its much less apt to
have catastrophic results if something ELSE wipes out /lost+found.  The
cleanup is only done on root's lost+found anyway, so it could probably
be omitted with virtually no ill effect, since lost+found subdirs on
other filesystems do not get automatically cleaned.

Check it out, that is probably the cause....

--------------- 

From: Judy Scheltema <judy at lobster.hou.tx.us>

Yes, same here. But like you, I have no clues as to why it is
happening. We are running 2.3.2 if that makes any difference.
If you find out why this is happening, I would appreciate it
if you would let me know, or if there's enough interest, post
it to the net.

---------------

From: Ted Chan <ys2!twc at murtoa.cs.mu.oz.au>

FYI Esix Rev C occasionally lost /lost+found (but none of the mounted
file system lost+found directories).  The Rev D update of Esix seems
to have fixed this (though I switched to the FFS, so that makes
the latter statement speculative, at best...).  Anyway, you might
try to contact SCO to see if they have a fix.  This problem may have
come from the AT&T port base.

From: Jay Vassos-Libove <libove at libove.det.dec.com>

Look in the regularly run stuff - either in the boot up (rc) files or
in the cron stuff. One of the standard system procedures is set up wrong -
it is supposed to clean old stuff out of /lost+found directories but it
actually looks more like:

find /lost+found -mtime +NN -exec /bin/rm -rf {} \;

which of course will throw out the baby (lost+found directory) with the
bathwater (the old lost+found files in the directory) if nothing ever
gets touched in lost+found for NN days.

---------------

That's all.

For now, I've modified the "find" in /etc/cleanup to only look for
files, and have removed the "r" option from "rm".

Thanks again to all who responded
-- 
Bernd Felsche,                 _--_|\   #include <std/disclaimer.h>
Metapro Systems,              / sold \  Fax:   +61 9 472 3337
328 Albany Highway,           \_.--._/  Phone: +61 9 362 9355
Victoria Park,  Western Australia   v   Email: bernie at metapro.DIALix.oz.au