Add support for creating native windows symlinks

Russell Davis
Fri Dec 23 21:38:00 GMT 2011

Sigh... I've already addressed all of these ponts (there are simple
ways to handle to all of them). I'm done fighting this battle.

Happy Festivus!

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

More information about the Cygwin-patches mailing list