data loss possible on forced kill

[andreaskremser]

Summary

when editing a huge (e.g. >80K lines) C-file, the editor sometimes gets unresponsive for extended time periods (up to several minutes).
Killing the hanging editor has in one instance deleted the bottom half of the file, while only a few lines have actually been edited.

Reproduction Steps

I tried this:

1. hx huge_c_file.c
   edit a few lines
   -> editor hangs, possibly due to language server
   force-kill hx

I expected this to happen:
In best case staying responsive ;)
Losing the latest changes is OK.

Instead, this happened:
Losing lines (about half the file), which have not been edited within the current editing session.. is unexpected.

Platform

Linux (fedora 36)

Terminal Emulator

konsole

Helix Version

helix 22.08.01

[dead10ck]

I actually suspected this was possible, but I wasn't sure. This confirms it for me. This is happening because every time we save, we truncate the file and write out the document text fresh:

helix/helix-view/src/document.rs

Lines 562 to 563 in e8f0886

	let mut file = File::create(path).await?;
	to_writer(&mut file, encoding, &text).await?;

I think the solution here is to write it to a temporary file first and then move over the existing file.

[startup-stack-sculptor]

@dead10ck Nice approach to first write to a different file instead of overwriting document directly.

[dead10ck]

It's the easiest way to avoid the problem. But I actually wonder what other editors do. This would be a really inefficient way to write a very large file.

[ngraham20]

I can poke at this

[ngraham20]

Ok, as far as quick research goes, it seems vim handles this by using swap files that are stored either in the working directory or a specified location. This swap file contains info like undo/redo histories and the state of the file as an autosave. This allows recoveries due to crashes. Maybe helix could do something similar?

https://www.cs.longwood.edu/VimSwap.html#:~:text=The%20reason%20this%20message%20comes,your%20undo%2Fredo%20history).

[the-mikedavis]

#401 might be the fix for this along those lines

[ngraham20]

Should we still add this temporary workaround, as that looks like a bigger code change?

[timokoesters]

I just had this problem and it wiped out the entire file. I was using rust formatter and the rust lsp and I think I triggered it by hitting ctrl-z followed by ctrl-c (because it seemed to hang).

A fix or temporary workaround would be great. Fortunately I didn't lose much data.