Boost C++ Libraries: Ticket #12119: Symlinks not supported when compiled on MSYS2 MinGW64 Windows 7

Tue, 12 Apr 2016 21:19:57 GMT

Can be worked around by using elevated privileges. It seems boost::filesystem requires elevated privileges on Windows when compiled in MSYS2 in order to create symlinks. When MSYS2 is started without elevated privileges, boost::filesystem will fail to create symlinks (and therefore not enable support in the compile).

Wed, 13 Apr 2016 19:12:54 GMT

Why does boost::filesystem require elevated permissions to create symlinks on MSYS2? There are several examples that manage to do without, for example the 'ln' command that works flawless with normal user permissions can create native symlinks. The same is true for Cygwin (on which MSYS2 was loosely based). Could this solution be ported to boost?

anonymous — Fri, 15 Apr 2016 22:28:23 GMT

I think you are saying (and if so, then I agree with you) that support for symlinks is not something that should be tested as a property of the build machine / environment, is this the case?

In all instances, if the target is Windows, then support for symlinks (such that Windows supports something approaching them) should be compiled into Boost.

Steven Watanabe — Sat, 16 Apr 2016 00:58:25 GMT

This issue is confusing two separate things. The "symlinks supported" message printed by the build system does not affect Boost.Filesystem. It only affects generation of headers under boost/ when building from git.

Second, the reason that symlinks work under cygwin (and probably msys2) is that cygwin has its own symlinks which are really just specially formatted text files. By default on Windows 7, a normal user does not have permission to create symlinks, which is why both Boost.Build and Boost.Filesystem fail to create them.

Sat, 16 Apr 2016 09:26:04 GMT

Dear steven_watanabe, in my impression what you say is not correct. I tested symlinks under MSYS2 (and Cygwin). I had to export MSYS='winsymlinks:nativestrict'

Sat, 16 Apr 2016 09:29:52 GMT

...so that 'ln -s' creates for me a directory symlink that is valid in Windows explorer. The link shows up with the link icon, and Windows explorer shows the directory contents when opening the link. No admin permission required. The same MSYS2 shell then fails to create symlinks with boost::filesystem. I found also more information here on what they call 'native NTFS symlinks' with Cygwin and MSYS2: http://stackoverflow.com/questions/18654162/enable-native-ntfs-symbolic-links-for-cygwin

Steven Watanabe — Sat, 16 Apr 2016 15:05:25 GMT

Your link essentially agrees with what I said. ln -s isn't creating a symlink in this case. It's actually creating a junction, which is slightly different and only works for directories.

Sat, 16 Apr 2016 20:52:25 GMT

Dear steven_watanabe, thanks for the feedback! I have now tried the same thing also with a text file from Cygwin, and it seems to work as well. Using Cygwin shell I need to export CYGWIN='winsymlinks', then I

Sat, 16 Apr 2016 20:53:11 GMT

...can create a symlink to a text file (no need for elevated permissions). Then I can open the link in Windows Explorer, which shows the contents of the text file in Notepad. Tested on Windows 7 64bit.

Steven Watanabe — Sat, 16 Apr 2016 21:10:57 GMT

Right, and the result is yet another thing that is similar to but not quite a symlink. Now you're creating a shortcut instead.

anonymous — Sun, 17 Apr 2016 08:45:54 GMT

I'm beginning to understand the differences. But can you advise what the implications are? Should boost::filesystem stick to symlinks the way they are currently supported? Or would 'junctions' and 'shortcuts' fulfill the same purpose (or even better)? Could this be a config option?

In other words, if boost would use 'junctions' and 'shortcuts' on Windows, would they behave like 'expected' from symlinks when accessed with boost::filesystem? Would file listing work? Would file reading work from a standard C/C++ application?