Backup files

[00sapo]

Basically, the same as the backup option in (n)vim: every time a file is changed and then saved to disk, just save its previous version somewhere to keep a backup of the last edit.

This should be easy to implement, as it is basically a modified version of :update. With the variable expansion feature, this could also be set up by users autonomously, but I think it's better to provide a command ad-hoc for this, with a configuration automatic_backup and another backup_directory. If backup_directory is ".", then files are backed up side-to-side to the original files with the addition of ~ to the filename.

This is super-useful when while developing you delete files by mistake.

[EriKWDev]

When my battary died on windows and later bootet up, the file I had opened in helix was just blank when I opened it again.

I would love an option to just keep rolling backups of the open buffers as well somewhere. Or even auto save after a certain time :(

[the-mikedavis]

I wonder if we need to fsync(2) the file after writing here?

helix/helix-view/src/document.rs

Lines 931 to 933 in 00e9e5e

	let mut dst = tokio::fs::File::create(&write_path).await?;
	to_writer(&mut dst, encoding_with_bom_info, &text).await?;
	Ok(())

I'm not sure that <tokio::fs::File as tokio::io::AsyncWriteExt>::flush does file syncing and if we don't explicitly sync then the kernel may hold the changes in memory from what I understand. (Although fsync(2) is not always respected by the underlying storage anyways)

[EriKWDev]

I want to make a thing clear, the computer doesn't crash in the middle of a save/":w", the computer just crashes for different reasons and helix happens to have the file open.

This is when, later when I've rebooted, the file is suspiciously completely empty.

I don't know if this happens if I were to use other editors since I use nothing but helix, but it has happened so many times now.. wether it is just battery going out while helix is open or complete computer crash.

If you have any idea how I can help I will happily do testing

[the-mikedavis]

It's a bit of a shot in the dark but you can try the syncing suggestion with a small change locally, the-mikedavis@9eb1e59

fsync(2) is meant to flush the changes to a file to disk and it's typically used by databases (for example against a write-ahead-log file) to try to ensure that a write isn't lost during a power outage / hard shutdown. Without syncing a write might not actually update the disk, so even if the machine is crashing some time after a :w, the changes to the file might still only be in memory and could be lost.

[the-mikedavis]

Actually the Tokio docs talk about flush not synchronizing. I've posted #10735 with that patch to fix this (if that is the issue here)

[EriKWDev]

I'm very glad you're looking into this and if the fsync fix is what's needed I will definately give it a try going forward!