Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uniwa!DIALix!metapro!bernie From: bernie@metapro.DIALix.oz.au (Bernd Felsche) Newsgroups: comp.unix.sysv386 Subject: SUMMARY: SCO Unix loses lost+found Message-ID: <1991Jun28.013340.8391@metapro.DIALix.oz.au> Date: 28 Jun 91 01:33:40 GMT References: <1991Jun23.065836.15692@metapro.DIALix.oz.au> Organization: MetaPro Systems, Perth, Western Australia Lines: 123 In <1991Jun23.065836.15692@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 Pat Myrto Judy Scheltema Ted Chan Jay Vassos-Libove Many thanks for your interest and clues. The first item contains the most extensive solution. Here's the summary: From: Roger Corneliussherpa!rac 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 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 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 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 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 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