Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!comp.vuw.ac.nz!am.dsir.govt.nz!marcamd!mercury!kcbbs!rden!rden
From: rden@rden.gen.nz (Robert den Hartog)
Newsgroups: comp.unix.sysv386
Subject: Re: SCO Unix loses lost+found
Message-ID: <1991Jun30.014704.360@rden.gen.nz>
Date: 30 Jun 91 01:47:04 GMT
References: <1991Jun23.065836.15692@metapro.DIALix.oz.au>
Sender: rden@rden.gen.nz (Robert den Hartog)
Reply-To: rden@rden.gen.nz (Robert den Hartog)
Organization: Private User
Lines: 34


In article <1991Jun23.065836.15692@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes:
>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)
>-- 
>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@metapro.DIALix.oz.au

The culprit is /etc/cleanup (one of roots cronjobs.)
I had the same problem myself, and tracked it down to the line in /etc/cleanup
that says:-
> find /lost+found -mtime +14 -exec rm -rf {} \; >/dev/null 2>&1

Thinking about it reveals that the entry "." is at risk if nothing's been
put into /lost+found for 14 or more days.  to fix, add the line:-
> touch /lost+found

just before the find.  Bit of a pain in the neck, expecially when you find out
that /lost+found is missing during a fsck.
-- 
The spelling mistakes aren't mine, they're the computers.
Hey, have a nice one.
		      Robert den Hartog. {rden|robert}@{rden|mercury}.gen.nz

Sorry, just me again, I seem to have lost my EOF somewhere.  Aha, there it is