Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!csd4.milw.wisc.edu!srcsip!tcnet!nis!sialis!rjg From: rjg@sialis.mn.org (Robert J. Granvin) Newsgroups: comp.sys.att Subject: Re: 3b1 startup: I CAN'T BELIEVE at&t was really this stupid! Keywords: destructive cleanup Message-ID: <1640@sialis.mn.org> Date: 7 Jul 89 01:34:18 GMT References: <1989Jul5.151150.25280@eci386.uucp> Reply-To: rjg@sialis.mn.org (Robert J. Granvin) Organization: Dr. Ho Laboratory and Day Care Center Lines: 32 >2. There is a find procedure to clean out the lost+found directory. >(This may be commented out by default, it certainly is here.) The >problem here is twofold - people don't check lost+found very often >so this could lead to an important file being thrown away before it >is missed - even worse, it is set up to discard any directory that >hasn't been modified in 7 days but when fsck puts something into >lost+found it keeps its original timestamp, so this means it doesn't >get to stay in lost+found for even a week, it could get removed >during the same reboot in which fsck put it into lost+found. Are you SURE about this? I'm not. The last time I manually cleaned out lost+found, I had files in there that were 14 months old. And believe me, the system was definately not up all that time... (OK, there were some days where the system was crashing more than I could control ... OK, there were a lot of days). Maybe something changed between OS releases? I've never seen this happen with 3.5 or 3.51 ... (Of course, I haven't looked either, but then, I've no reason to... :-) Of course, we should also be careful about claims and screams of "stupidity". Some things may not be stupid, and some stupid things may not have been done by ATT. -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ BITNET: rjg%sialis.mn.org@cs.umn.edu __National Information Services__ UUCP: ...amdahl!bungia!sialis!rjg "I'll just go bang my head on a wall & figure out why I abuse myself so much"