Add support for creating native windows symlinks

Corinna Vinschen
Tue Dec 20 15:34:00 GMT 2011

On Dec 19 11:31, Russell Davis wrote:
> > I don't think it's the right approach to let Cygwin create symlinks
> > which are only partially usable in the POSIX environment...
> Huh? I think you're not fully understanding my suggested approach. As
> I pointed out in my previous message, it should be 100%, fully usable
> in the POSIX environment. Again: any path that might be problematic as
> a Win32 path can just be stored as a POSIX path, and would fall into
> the bucket of "works inside cygwin but not outside".

How are you going to check the difference?

Btw., you can write the Win32 and the POSIX path into the reparse point
since the reparse data buffer contains two strings, the so called
SubstituteName and the so called PrintName.  SubstituteName is the
native NT path which is used internally to resolve the path, the
PrintName is used by CMD or Explorer for printing purposes.  If you put
the POSIX path into PrintName, CMD shows the POSIX path and Explorer
shows an empty string as target location.  Of course you can't do that
using the CreateSymbolicLink call.

However, how do you make sure that the file vs directory flag is set
correctly, given that the file or directory doesn't have to exist at the
time the symlink gets created?  Neither CMD nor Explorer handle this
situation gracefully.

How do you handle the fact that remote symlinks only work if certain
settings are made (fsutil)?  And how do you handle the situation that
native symlinks don't work on pre-Vista machines, which also makes them
unsuitable for remote shares?  Some symlinks on a share are created this
way and some symlinks are created that way and depending on the machine
from where you try to access them they are usable or not.

As I said, I experimented a lot with native symlinks in the past and one
way or the other they don't quite work as expected.  I'm not overly keen
to support writing them.  The hassle with the required
SE_CREATE_SYMBOLIC_LINK_NAME privilege, the extra hassle that they don't
work on remote drives without explicitely enabling them via fsutil, the
fact that remote pre-Vista machines don't get them transparently
translated at all, the nonsense with the file/directory flag...  I'm
quite content to read them in Cygwin on a local drive but otherwise
leave them alone.  for those who really want them there are tools out
there to create them, but in these cases the tool provider has to take
the support burden.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-patches mailing list