Symlinks not supported when compiled on MSYS2 MinGW64 Windows 7

[Mario Emmenlauer <mario@…>]

I will try to follow up this issue a bit further myself, but wanted to report it ASAP to help others and track the progress. I compiled the boost package on MSYS2 (standard package source compile) and found that it prints "symlinks supported: no". So far I could not find why this is the case, because symlinks should certainly be supported on this system/environment. When I force-disable this check, symlink support does get compiled into boost, and I get further.

Creating symlinks still fails for me, but this might be an unrelated (permission) issue: It fails now with "Got exception boost::filesystem::create_symlink: A required privilege is not held by the client:".

[Mario Emmenlauer <mario@…>]

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).

[Mario Emmenlauer <mario@…>]

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]

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]

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.

[Mario Emmenlauer <mario@…>]

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'

[Mario Emmenlauer <mario@…>]

...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]

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.

[Mario Emmenlauer <mario@…>]

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

[Mario Emmenlauer <mario@…>]

...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]

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]

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?