[RFC] Symlink handling in core

[GwendolenLynch]

Background

Bolt uses an abstracted file system layer, based on Flysystem.

Due to supporting a wide variety of platforms, Flysystem doesn't (and for all intensive purposes, can't) support symlinks, and by default will throw an exception when trying to access them. This is correct, and desired, design & behaviour!

Problem in core

There are locations in core file systems, for example that build CSS & JS on development deployments, are likely to have file/directories that are symlinked. This is a valid use case.

However, should someone access one of these directories, an exception will be thrown, taking down the application.

One good example of where this is out of the theme developer's hands, comes with using NPM/Bower components, as some will add symlinks.

Another (but obviously less relevant), is core development (the personal inspiration for asking this question), app/src/node_modules/ … /me mumbles something about NodeJS … and trying to build external tools (needing access to an instance of app) to make life easier.

Regardless, in a development environment, there are valid reasons a developer might have symlinks in place to aid in build/deployment activities on the command line, or using external tools.

Proposed solution

Flysystem's optional behaviour for symlinks is passing Local::SKIP_LINKS as the final constructor parameter.

This would have the end result of them just not appearing in the web UI. Maybe a note on the file browser side bar indicating "Note: Symlinked files & directories are not supported & will not be visible."

[bobdenotter]

See also #5460

I would very much like not to hide symlinks, and be able to at least read over them.

[GwendolenLynch]

I would very much like not to hide symlinks, and be able to at least read over them.

The problem then becomes you're potentially linking to resources that you don't want publicly accessible, and it might show, but if it isn't accessible? Then what if you have said FS mounted on a remote that doesn't support them?

[bobdenotter]

Then what if you have said FS mounted on a remote that doesn't support them?

Well, I think that 'd be the problem of the person trying to make symlinks on a system that doesn't support it. .

It would be a shame if we'd drop them entirely, even while most people use "local" and we'd cut them out of a useful feature because of this.

[GwendolenLynch]

Regardless, it is still work that has to be done quite extensively in our bolt/filesystem code … Volunteers? 😉

What I am questioning as a first step is simply not crashing the app when it encounters a symlink. As the underlying library with throw an exception by default, or skip them and continue as normal when constructed otherwise.

[GwendolenLynch]

So more-or-less Step 1 for #5460

[bobdenotter]

Yes, i'm always a fan of "not crashing" 👍

[bobdenotter]

As discussed in the meeting: This is partially closed by #6744, and partially a duplicate of #5460, so we'll close this for now.