Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.editors
Subject: Re: :wq (Re: One user's editor wish list)
Message-ID: <11736@dog.ee.lbl.gov>
Date: 3 Apr 91 22:21:43 GMT
References: <2900@wn1.sci.kun.nl> <1991Mar29.160622.5445@informix.com> <11638@dog.ee.lbl.gov> <3234@charon.cwi.nl>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 33
X-Local-Date: Wed, 3 Apr 91 14:21:44 PST

>In article <11638@dog.ee.lbl.gov> I noted:
>>... You should *always* write [`vi -r'] recovered files to a new
>>(temporary) name and compare the original and new files manually,
>>as it is possible for recovered files to be partially mangled.

In article <3234@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>I think it would be better to have a single recover file command
>that would replace 'vi -r', 'ex -r', and friends.

I agree (and this would be true even if recovery were infallible).

>As for the partially mangled bit: if this does occur that is also bad
>design.  There is no reason at all that an aborted edit session would
>leave a mangled internal file.

To get this right, you must in essence duplicate a database transaction
system; this is notoriously difficult and/or slow on conventional Unix
machines.  vi simply tries hard not to mangle text, but if you port BSD
often enough%, you will eventually run `vi -r' only to see

	LOST
	LOST
	LOST

on your screen....

-----
% This implies `use flaky pre-alpha systems', like the one that is not
  even debuggable yet on my SparcStation... I have not got past kernel
  startup yet, much less get ready to lose vi files.  But I have hopes. :-)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov