hugo: Temporary files not ignored when (re)building site
What version of Hugo are you using (hugo version
)?
v0.62.2-83E50184/extended linux/amd64
Does this issue reproduce with the latest release?
Yes
I wasn’t sure why I’d often be seeing the live preview of my site break on saves, when the state on the filesystem was fine. Digging into the no such file or directory
message, I see this has to do with Emacs lock files being followed where I don’t believe they should be. The full message is in the form of:
Error: add site dependencies: load resources: loading templates: walk: Readdir: decorate: lstat $SITE_ROOT/layouts/partials/$USER@$MACHINE.$PID:$BOOT: no such file or directory
Of course the lock file is a symlink pointing to this path, with the prefix .#
added to the file name in an unsaved, modified buffer.
This is true for both content and templating files, as long as a buffer is open with a modified version. This happens for both hugo
and hugo server
commands. It’s easiest to reproduce by triggering a rebuild (running hugo
or saving a change to a different file with hugo server
running), and having a file open in emacs with a modified state so the lock symlink exists. It seems to also happen as a race condition when editing only a single file with hugo server
running, where the rebuild reaches the lock symlink before emacs removes it.
I believe hugo server
ignores events around temporary files so a rebuild isn’t triggered, but does not ignore these files in the building of a site. I further believe that, well… that’s the wrong behavior.
I have a fix that solves my issue, see imminent pull request.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 25 (7 by maintainers)
Commits related to this issue
- Skip over temporary files when building pages The same logic for ignoring a temp-related filesystem event in `handleEvents` from `commands/hugo.go` is now used to ignore files when (re)building the s... — committed to obar/hugo by obar 4 years ago
- Skip over temporary files when building pages The same logic for ignoring a temp-related filesystem event in `handleEvents` from `commands/hugo.go` is now used to ignore files when (re)building the s... — committed to obar/hugo by obar 4 years ago
This bug still reproduces per instructions in the first post. It has come up on discourse again within the past month. The work around for emacs users is to turn off lockfiles (see previous discussion in this thread), but that has other side effects for emacs users. I don’t know about turning off temporary files in other editors.
Fortunately the patch doesn’t need any updates, it works today on master (see the latest comment on the pull request).
Can I call in a fellow Canadian for help, could you review the pull request to close this bug @anthonyfok ? It’s small and doesn’t add any new logic so I would think the review should be painless… famous last words 😉
I’m not sure I understand why the choice is between no filter and a hard coded filter? Why not just some option
.hugoignore
in analogy to how git ignores files? That seems like a decent compromise, and might have other uses? Or am I missing some aspect of the discussion (I haven’t looked through the other related discussions,I understand that globally disabling the creation of lock files within Emacs is undesirable for some users.
You can locally (per project) disable the creation of lock files by placing a
.dir-locals.el
file in the root of your project directory. For example:I tested this briefly this evening and it seems to work. Given that lock files exist solely to prevent multliple users from simultaneously modifying the same file, within the context of a Hugo project this approach seem more like a solution than a workaround.
It would be nice if Hugo would ignore temporary files entirely. However, the biggest problem for me is that even once these temporary files disappear, the only way I have found to get
hugo server
to notice and successfully serve the site again is to restart it. This breaks my thought process and work flow, every time.I agree. I have no idea why Emacs chooses to litter my directory with lock files and backup files. I guess that’s just the way it’s always been, and there’s too much intertia to change the default behavior. Oh well, at least it is configurable.