Re: vim file write mode on journaling fs.

[Seth Mos <knuffie@xs4all.nl>]

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