Hugo live reload issue with Helix backup (.bck) files

[faresbakhit]

Suggestion

Can an option be added to disable backup files and modify the files directly when saving changes with the write:* family of commands?

Current Behavior

The current behavior can be tested by invoking inotifywait -m . from inotify-tools, opening a file, modifying the file, and saving the change with :w.

Output from inotifywait on my machine using helix 24.7 (079f5442):

./ OPEN example.txt
./ ACCESS example.txt
./ CLOSE_NOWRITE,CLOSE example.txt
./ MOVED_FROM example.txt
./ MOVED_TO example.txtU77clA.bck
./ CREATE example.txt
./ OPEN example.txt
./ MODIFY example.txt
./ CLOSE_WRITE,CLOSE example.txt
./ ATTRIB example.txt
./ DELETE example.txtU77clA.bck

tl;dr: Helix reads example.txt contents into memory, and upon saving it moves (not copy) example.txt to example.txtXXXXXX.bck, creates example.txt, saves the new changes to example.txt, and removes example.txtXXXXXX.bck.

I'm not sure why Helix need to do this and the code doesn't help me either:

helix/helix-view/src/document.rs

Lines 940 to 970 in 84fbadb

	let backup = if path.exists() {
	let path_ = write_path.clone();
	// hacks: we use tempfile to handle the complex task of creating
	// non clobbered temporary path for us we don't want
	// the whole automatically delete path on drop thing
	// since the path doesn't exist yet, we just want
	// the path
	tokio::task::spawn_blocking(move || -> Option<PathBuf> {
	let mut builder = tempfile::Builder::new();
	builder.prefix(path_.file_name()?).suffix(".bck");
	let backup_path = if is_hardlink {
	builder
	.make_in(path_.parent()?, |backup| std::fs::copy(&path_, backup))
	.ok()?
	.into_temp_path()
	} else {
	builder
	.make_in(path_.parent()?, |backup| std::fs::rename(&path_, backup))
	.ok()?
	.into_temp_path()
	};
	backup_path.keep().ok()
	})
	.await
	.ok()
	.flatten()
	} else {
	None
	};

Use Case

Many tools that monitor a set of files/directories for changes and does something when files are created/changed/removed and don't produce the intended behavior since they get multiple events (CREATE -> CREATE -> REMOVE) instead of one MODIFY event.

Such tools include latexmk, hugo, and other static site generators or 'live' coding environments (although, I only use latexmk and hugo)

This is output from hugo server --disableFastRender:

Template added /partials/head.html5iipqu.bck
Template added /partials/head.html

And as a result it doesn't update the generated files properly. With the new option the output should be:

Template changed /partials/head.html

[pascalkuthe]

It's inktify 101 that you need to properly track files and can't just assume that files will be modified woth a single read. Editors like vim do that for example. It's the only way to avoid corrupting files if the editor crashes.

If these tools don't properly account for these schemes then their file watcher implementation is broken

[David-Else]

@pascalkuthe I have experienced the problem with Hugo and Helix myself, and confirmed it does not happen when using Vim. Do you know why this could be? Here is the issue in Hugo, @bep is the Hugo maintainer: gohugoio/hugo#12677 (comment)

[pascalkuthe]

they hardcoded vim file names instead of implement a robust/general solution

[David-Else]

I added a fix to Hugo: gohugoio/hugo#12856

EDIT: It was merged, should be fixed, please report if there are any more problems!

[faresbakhit]

@David-Else Thank you! I'll try compiling Hugo later and test it, but the patch should suffice.

As the bug was on Hugo's end, as @pascalkuthe said, I'll rename the discussion to reflect that so anyone with the same issue can just search for Hugo and upgrade to latest version with the patch.