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

Most upvoted comments

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:

;;; Directory Local Variables
;;; For more information see (info "(emacs) Directory Variables")

((nil . ((create-lockfiles . nil)))) 

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.

the default behavior for a tool shouldn’t require the user to figure out things like that

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.