Remove symlink support for the input files

[bep]

This relates to #11543 and others, a part of a major overhaul/simplification/improvement in how Hugo process content (where content includes all files being read and processed as part of the build process).

This work is motivated by several things:

• We need to improve on the partial builds.
• We need Hugo to handle larger data sets and use less memory.
• We need to simplify things to make it possible to add the features planned, but also to make the code easier to maintain.

Working on the above, I have so far just ignored our support for symlinked directories, but now is the time for me to consider putting that support back into my development branch or not.

My main argument for removing it is that it should not really be needed anymore as we got virtual file mounts, e.g.:

[[module.mounts]]
source = "/foo/bar"
target = "content"
lang = "en"

In contrast to symlinks, these mounts are OS and file system agnostic (even work for files/dirs mounted from GitHub), and Hugo knows about them, so we can react to configuration changes.

Some other issues with symlinks are:

• They're very hard to reason about when files changes and we need to rebuild, and this becomes almost impossible on structural changes (symlinks that is deleted, renamed etc.)
• There are security concerns, which is why Hugo only allows symlinks in the main project (not in themes/modules).
• They behave differently on different OSes (on Windows, you need to be an admin to create them).
• All this symlink checking also has a performance cost.

But most importantly, I don't want us to spend many hours implementing and maintaining a feature that I think is very rarely used (I have never used it).

[hugo-sid]

Just wanted to express my support. I agree with your reasoning to remove support for symlinks.

I think is very rarely used (I have never used it).

I don't think why someone will use symlinks, when module.mounts is available.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.