Symbolic link bug in recent Cygwin DLL build

[Mark Geisert]

Hi Corinna,

Corinna Vinschen wrote:
> Hi Mark,
> 
> On Apr 15 23:53, Mark Geisert wrote:
>> After installing a recent DLL built from the git source tree I noticed:
>>
>> ~ ln -s /tmp/foo .
>>
>> ~ ls -l foo
>> lrwxrwxrwx 1 Mark None 12 Apr 15 23:44 foo -> /mnt/tmp/foo
> 
> Huh?  That works for me, independently of /tmp/foo existing or not:
> 
>    $ ln -s /tmp/foo .
>    $ ls -l foo
>    lrwxrwxrwx 1 corinna Users 8 Apr 16 10:38 foo -> /tmp/foo
> 
> Since you're building the DLL yourself, can you please debug this with
> GDB?  It would be very important to find out what on your system adds
> the /mnt prefix!
> 
> It could occur in creating the symlink, that's in path.cc, function
> symlink_wsl(), or it could occur in reading the symlink, path.cc,
> function check_reparse_point_target(), in the else if (rp->ReparseTag ==
> IO_REPARSE_TAG_LX_SYMLINK) branch at line 2534.
> 
> As for /mnt itself, it's the WSL equivalent to the cygdrive prefix.
> When creating WSL symlinks, Cygwin converts the cygdrive prefix to
> /mnt, and when reading WSL symlinks, a leading /mnt is converted
> to the current cygdrive prefix on the fly.
> 
> We should just move further discussions to the cygwin-developers ML.

Sorry about the ML flub.  Your mention of cygdrive prefix gave me some dread. 
 From day 1 I've suppressed the prefix on any Cygwin machine I've administered; 
I use /c or /d etc to refer to drives.  That means having this line in /etc/fstab:
     none / cygdrive binary,posix=0,user 0 0

The "/mnt" is being added at path.cc:1892.  It's replacing the current cygdrive 
prefix with "/mnt".  I'm unclear why we're in a function named symlink_wsl() 
since I'm not using WSL at all.  Maybe it means WSL-compatible?  OK if so.

Does that string replacement need to be skipped in this situation of "empty" 
cygdrive prefix?  Or is it something more subtle?

..mark