Mkay, I'll run inotifywait next time I'm working on my site and confirm what Nanoc's doing. Perhaps a directory gets touched (by the kernel) first, triggers inotify and LiveReload catches that.
You're claiming Nanoc's renaming files over existing files, right? It's not a delete-then-move action?
Presumably at some point the output file has to be missing entirely, otherwise the web server wouldn't report a 404.
This is pretty weird.
Curiously, I'm seeing a delete happen ...
19:51:36 DELETE public/articles/foo/index.html
19:51:36 CREATE public/articles/foo/index.html
19:51:36 MODIFY public/articles/foo/index.html
19:51:36 CLOSE_WRITE,CLOSE public/articles/foo/index.htmlThis with:
inotifywait --recursive --monitor public --format "%T %e %w%f" --timefmt "%T" -e modify -e attrib -e close_write -e moved_to -e moved_from -e move -e move_self -e create -e delete -e delete_self
And that triggered a race which LiveReload won, reloading before the
create and coming up with "File not found".
I think I know why this is happening. Nanoc's not using renaming, it's using hard linking.
https://github.com/nanoc/nanoc/blob/4.10.1/nanoc/lib/nanoc/base/services/item_rep_writer.rb#L59 calls
https://ruby-doc.org/stdlib-2.4.1/libdoc/fileutils/rdoc/FileUtils.html#method-c-ln
https://github.com/nanoc/nanoc/blob/4.10.1/nanoc/lib/nanoc/base/services/item_rep_writer.rb#L59 calls
FileUtils.ln with force: true. Force, as per Ruby's implementation, just unlinks it before creating a new link:https://ruby-doc.org/stdlib-2.4.1/libdoc/fileutils/rdoc/FileUtils.html#method-c-ln
That explains the
delete inotify event before create and explains the race condition.
..given that in one branch of the code
temp_path is set to not a true temporary path, but the actual filename from the content directory.
Moving stuff in place can work under certain conditions, but not all
(e.g. the input file in
content/ might be hardlinked to what is in output/!)
I'm not sure how hard linking helps for compilable items then.
Do you mean textual, or binary?
It seems there's a pretty good opportunity for optimizing "compilation" of passed through binary items, too — not to compare them byte by byte with
FileUtils.identical, but check if they're hard links. If I change the hard linked file in content, it's guaranteed to already match in output.
Yeah, I'm seeing it approximately every 10 updates. Fast computer, what can I say. :P
There's one
index.html compiled to /tmp. That's not around after the compile ends. Why not move it immediately?
Identical between
content and output, that is.
Even the copy fallback seems wasteful if I understand the flow correctly. Given a compiled file (like Markdown -> HTML)
temp_path referes to a file that's deleted after the method finishes. That file shouldn't be copied and then deleted, it should only be moved.
(Though if hardlinking fails,
mv will likely be equivalent to a cp + rm anyway)
Though for your particular problem, perhaps a 100ms delay somewhere would be enough
I am not sure how to introduce that, however.
(Otherwise, you end up with something that is so configurable that the config file becomes overwhelming)
I've used LiveReload generally for a long time and I remember it requiring quite a bit of tweaking to find the sweet spot for each project — sometimes compiling JavaScripts or CSS to the output directory took a long time and having the browser constantly reload during that time was annoying. :P
Ideally Nanoc should signal a reload only once it has actually finished its compile cycle.
But with LiveReload being part of
adsf instead of Nanoc, that may be more difficult practice than in theory.