bernie@metapro.DIALix.oz.au (Bernd Felsche) (06/23/91)
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
rden@rden.gen.nz (Robert den Hartog) (06/30/91)
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