Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!gymble!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: Another reason why - really /tmp
Message-ID: <1784@umcp-cs.UUCP>
Date: Tue, 8-Oct-85 05:59:00 EDT
Article-I.D.: umcp-cs.1784
Posted: Tue Oct  8 05:59:00 1985
Date-Received: Fri, 11-Oct-85 07:20:20 EDT
References: <1149@brl-tgr.ARPA> <182@graffiti.UUCP> <764@rlgvax.UUCP> <> <779@nmtvax.UUCP> <140@codas.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 13

> fsck never misses a lost+found directory, and you probably wouldn't
> care to recover any lost files in /tmp anyway.

Not so!  Not, at least, in 4.2BSD.  In particular, if `fsck' wants
to reconnect a file, but there is no lost+found, it will abort a
`preen' style fsck rather than clearing the inode.  And `ex'---and
thus vi---temporary files are stored in /tmp; but they are still
useful, after a crash, for recovering most if not all of your
editing sessions.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu