On Fri, 10 Aug 2001, Bram Moolenaar wrote:
>
> Seth Mos wrote:
>
> > One sync exit wouldn't make that much of difference, You can only exit a
> > program once :-)
>
> You wouldn't want to sync the whole disk, just the files that Vim wrote.
> Would require remembering which files were written. And you would want the
> sync to happen when Vim doesn't exit anyway. No, if the syncing is to be
> done, it's better to do it immediately when the file was written.
I agree.
> > > I wonder why the swap file wasn't deleted. Vim must have deleted it, and
> > > if the metadata for the text file was flushed, why wasn't the swap file
> > > metadata flushed?
> >
> > I don't know but the swapfile had not the changes but was a exact copy of
> > the same file.
>
> Do you mean after recovery, or did you look in the swapfile itself? When Vim
> overwrites the original file, the swap file is flushed, because it can't use
> the original file to recover from then. That does create overhead, I don't
> see how that can be avoided. In this case it indeed helps to recover your
> text.
After recovery. I can recover the whole file with vi -r.
So somehow the entire buffer ended up there iinstead of the changes.
> > The thing is that the only application that people have managed to
> > produce NULL character files with so far has been vim :-/
> > If I edit a file with pico it is in one piece if I save it. I will
> > scavenge the pine sources to see what pico is doing.
>
> Does it only happen when overwriting an existing file? I would expect the
> same to happen when writing a new file. E.g. when using:
I asume this is the case.
> cp file1 file2
> rm file1
>
> Could you end up with an invalid file2 while file1 has been deleted already?
I will try this in a moment. Quiting my ssh session first :-)
No journaling fs can recover that.
Cheers
Seth
|