Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site codas.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!akguc!codas!mikel
From: mikel@codas.UUCP (Mikel Manitius)
Newsgroups: net.unix-wizards
Subject: Re: Another reason why - really /tmp
Message-ID: <140@codas.UUCP>
Date: Thu, 3-Oct-85 22:00:42 EDT
Article-I.D.: codas.140
Posted: Thu Oct  3 22:00:42 1985
Date-Received: Mon, 7-Oct-85 03:55:23 EDT
References: <1149@brl-tgr.ARPA> <182@graffiti.UUCP> <764@rlgvax.UUCP> <> <779@nmtvax.UUCP>
Organization: AT&T Information Systems (SDSS) - Orlando
Lines: 28

> >
> >I also changed /etc/rc to clear /tmp with an rm -r
> >
> 
>     However, you should realize that if /tmp is a filesystem
> in its own right, the lost+found directory will be consumed with the
> rm -r command. Do you really want to do that? Of course it doesn't take
> much to bring it back, but fsck will sorely miss it.
> 
>    Roger Levasseur
>    New Mexico Tech

fsck never misses a lost+found dirrectory, and you probably wouldn't
care to recover any lost files in /tmp anyway. Note one point, if /tmp
is on a seperate filesystem, make sure that it gets mounted before you
do the rm -r /tmp, otherwise you will nuke /tmp and there will be no
place to mount it.

It is also probably safer to "cd /tmp; rm -r .", even though you can't
remove a directory on which a filesystem is mounted, it is not a good
idea to try.
-- 
                                        =======
     Mikel Manitius                   ==----=====    AT&T
     ...!{ihnp4!}codas!mikel         ==------=====   Information Systems 
     (305) 869-2462                  ===----======   SDSS Regional Support
     AT&T-IS ETN: 755                 ===========    Altamonte Springs, FL
     My opinions are my own.            =======