Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site onfcanim.UUCP
Path: utzoo!watmath!watnot!watcgl!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: net.unix-wizards
Subject: Re: Another reason why - really /tm
Message-ID: <14690@onfcanim.UUCP>
Date: Fri, 27-Sep-85 10:47:36 EDT
Article-I.D.: onfcanim.14690
Posted: Fri Sep 27 10:47:36 1985
Date-Received: Sat, 28-Sep-85 06:30:12 EDT
References: <2279@sunybcs.UUCP> <13700108@uiucdcs>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: ONF, Montreal
Lines: 26

In article <13700108@uiucdcs> acheng@uiucdcs.CS.UIUC.EDU writes:
>
>The "rm -r" may remove the lost+found directory in /tmp.  That
>may cause trouble when fsck needs it.  But then, one may say /tmp
>is for scratch and no big deal if files get lost there.  Well...

Note that /tmp contains a lost+found directory only if it is a separate
filesystem.

However, if you do delete lost+found, and then the system crashes, and
fsck finds an unattached file in /tmp and no lost+found directory to
link it into, fsck and the entire automatic reboot will fail.  Do you
really want to get phoned at 7AM because the system didn't come back
up by itself?

One solution is to do a newfs on /tmp every boot.

A better one is to not touch /tmp at all at boot time, but use a find
run from the crontab to clean it up.  This way, when the system recovers
from a crash, the temp files are still there.  There are few things more
annoying than logging in after a crash and having a mail message from
ex/vi telling you that it carefully preserved the info allowing you to
reconstruct your editing of /tmp/Re121345 or /tmp/article188 when, in fact,
the boot removed the originals.  It's pretty easy to set up a find that
deletes files that haven't been accessed in so many days, and any directories
*except* lost+found that haven't been accessed recently.


Brought to you by Super Global Mega Corp .com