ddfreyne on enable-binary-compiled-content-cache
Enable binary compiled content … Use copy-on-write for binary co… (compare)
ddfreyne on main
Upgrade dependencies Use Bundler 2.x (compare)
ddfreyne on main
Upgrade nanoc, nanoc-live (compare)
ddfreyne on main
nanoc-live: Set version to 1.0.… nanoc-live: Add release notes f… Set version to 4.11.23 and 1 more (compare)
ddfreyne on 4.11.23
nanoc-live: Set version to 1.0.… nanoc-live: Add release notes f… Set version to 4.11.23 and 1 more (compare)
ddfreyne on nanoc-core-v4.11.23
nanoc-live: Set version to 1.0.… nanoc-live: Add release notes f… Set version to 4.11.23 and 1 more (compare)
ddfreyne on nanoc-cli-v4.11.23
nanoc-live: Set version to 1.0.… nanoc-live: Add release notes f… Set version to 4.11.23 and 1 more (compare)
ddfreyne on nanoc-live-v1.0.0b8
nanoc-live: Set version to 1.0.… nanoc-live: Add release notes f… Set version to 4.11.23 and 1 more (compare)
ddfreyne on main
Set up GitLab CI Merge branch 'gitlab-ci' into '… (compare)
ddfreyne on gitlab-ci
Set up GitLab CI wip (compare)
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?
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.html
This 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
create
and coming up with "File not found".
FileUtils.ln
with force: true
. Force, as per Ruby's implementation, just unlinks it before creating a new link:delete
inotify event before create
and explains the race condition.
temp_path
is set to not a true temporary path, but the actual filename from the content directory.
content/
might be hardlinked to what is in output/
!)
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
.
index.html
compiled to /tmp
. That's not around after the compile ends. Why not move it immediately?
content
and output
, that is.
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.
mv
will likely be equivalent to a cp
+ rm
anyway)
adsf
instead of Nanoc, that may be more difficult practice than in theory.