Symbolic Links With Terminating Slash Don't Function Properly

[raycardillo]

Brief Description:
I was trying to create a symbolic link to a specific directory on the Windows mount to my home dir for convenience. I did this using auto complete with a TAB (which added a terminating slash). Then I quickly discovered that the symbolic link created was only ever returning the dir that was directly linked to (never anything deeper - even if specify an invalid path). I fixed this by creating the link without the terminating slash, and that worked fine. However, I still wanted to report the problem in case it helps in some other context, or just so others know about this odd behavior. See commands below to see what I mean.

Windows build number:
14388.0

Commands to Reproduce the Error:

rcardillo@LAPDOG:~$ ln -s /mnt/c/WORK_REPO/ ~/WORK_REPO
rcardillo@LAPDOG:~$ ls -al ~/WORK_REPO
lrwxrwxrwx 1 rcardillo rcardillo 17 Jul 13 01:20 /home/rcardillo/WORK_REPO -> /mnt/c/WORK_REPO/
rcardillo@LAPDOG:~$ ls -al /mnt/c/WORK_REPO/github/
total 4
drwxrwxrwx 2 root root 0 Jul 13 00:56 .
drwxrwxrwx 2 root root 0 Jul 13 00:32 ..
rcardillo@LAPDOG:~$ ls -al ~/WORK_REPO/github/
total 44
drwxrwxrwx 2 root root 0 Jul 13 00:32 .
drwxrwxrwx 2 root root 0 Jul 13 00:32 ..
drwxrwxrwx 2 root root 0 Jul 13 00:32 angular-1.3.5
drwxrwxrwx 2 root root 0 Jul 13 00:32 angular-1.3.5.zip
drwxrwxrwx 2 root root 0 Jul 13 00:32 bootstrap-3.3.1-dist
drwxrwxrwx 2 root root 0 Jul 13 00:32 github
drwxrwxrwx 2 root root 0 Jul 13 00:32 MediaHelpers
rcardillo@LAPDOG:~$ ls -al ~/WORK_REPO/github/any/thing/else
total 44
drwxrwxrwx 2 root root 0 Jul 13 00:32 .
drwxrwxrwx 2 root root 0 Jul 13 00:32 ..
drwxrwxrwx 2 root root 0 Jul 13 00:32 angular-1.3.5
drwxrwxrwx 2 root root 0 Jul 13 00:32 angular-1.3.5.zip
drwxrwxrwx 2 root root 0 Jul 13 00:32 bootstrap-3.3.1-dist
drwxrwxrwx 2 root root 0 Jul 13 00:32 github
drwxrwxrwx 2 root root 0 Jul 13 00:32 MediaHelpers
rcardillo@LAPDOG:~$

Notice how in the first command, I demonstrate that the github directory is actually empty, but when I use the symbolic link, it returns the contents of the directory that the link points to. Likewise, event when I specify an invalid path, it will always return the contents of the directory the link points to.

[tsbarnes]

I can verify this. Symlinks to directories where the target contains double slashes (for example, /home/foo//bar) suffer a similar problem. Symlinks to files with double slashes in the target just return an empty file.

[mzzzoozz]

I found that either link DryFS' target or symbolic on DryFS has this problem.
And rm command work incorrect, it will remove anything if rm directory not exist.
That is a little terrible.

[benhillis]

Thank you for reporting this, this is definitely a bug. I've filed a bug internally and will start taking a look at a fix.

[baroso]

Is this somehow related to Following symlinks does not work #600?
I just installed Windows 10 Insider Preview 14390 and the problem still exists!?

[a8ksh4]

Subscribed. I'm seeing this issue, too. With a "/" on the end of the symlink target path, it has trouble.

[JasonLinMS]

Thanks for reporting this issue, this issue has been fixed internally and will be in a future flight.

[hpssjellis]

Can someone check if the tilda "~/" is causing issues with symlinks.

The following code works

ln -s /folder/folder /home/me/mylink

And this following code does not work for me

ln -s /folder/folder ~/mylink

[aseering]

@hpssjellis -- both of the commands that you posted work correctly for me:

aseering:~$ ln -s /mnt ~/mylink
aseering:~$ ls mylink
c
aseering:~$ rm mylink
aseering:~$ ln -s /mnt /home/aseering/mylink
aseering:~$ ls mylink
c

[hpssjellis]

Weird. On a fresh install of Bash on Windows mine is now working for

ln -s /mnt ~/mylink

I did however find a work around if anyone else is having troubles with the ~/

ln -s /mnt /home/$USER/mylink

which also works

[russalex]

Issue is fixed in the new Insider build - 14901.

[onomatopellan]

@russalex I think the issue that is fixed is #671.
But I still can reproduce the bug of this thread on build 14901.
ln -s /mnt/g/CODING/
creates a bad symlink with the loop symptoms (you can see the 2 slashes at the end when doing "ll" in the home folder)
lrwxrwxrwx 1 onoma onoma 14 Aug 12 20:02 CODING -> /mnt/g/CODING//

[russalex]

Doh! @onomatopellan, you are correct. When testing I ran ln -s /mnt/c/tmp ~/temp instead of ln -s /mnt/c/tmp/ ~/temp. Forgot the all important '/' at the end of tmp. Output between the two on 14901:

russ@DESKTOP-K1JHN54:~$ ln -s /mnt/c/tmp ~/temp
russ@DESKTOP-K1JHN54:~$ ll temp
lrwxrwxrwx 1 russ russ 10 Aug 12 12:02 temp -> /mnt/c/tmp/
russ@DESKTOP-K1JHN54:~$ ll temp/foo
total 4
drwxrwxrwx 2 root root 0 Aug 12 12:01 ./
drwxrwxrwx 2 root root 0 Aug 12 12:01 ../
-rwxrwxrwx 1 root root 0 Aug 12 12:01 bar.txt*
drwxrwxrwx 2 root root 0 Aug 12 12:01 baz/
-rwxrwxrwx 1 root root 0 Aug 12 12:01 foo.txt*
russ@DESKTOP-K1JHN54:~$ ll temp/foo/baz
total 0
drwxrwxrwx 2 root root 0 Aug 12 12:01 ./
drwxrwxrwx 2 root root 0 Aug 12 12:01 ../
-rwxrwxrwx 1 root root 0 Aug 12 12:01 baz.txt*
russ@DESKTOP-K1JHN54:~$ rm temp
russ@DESKTOP-K1JHN54:~$ ln -s /mnt/c/tmp/ ~/temp
russ@DESKTOP-K1JHN54:~$ ll temp
lrwxrwxrwx 1 russ russ 11 Aug 12 12:02 temp -> /mnt/c/tmp//
russ@DESKTOP-K1JHN54:~$ ll temp/foo
total 12
drwxrwxrwx 2 root root 0 Aug 12 12:01 ./
drwxrwxrwx 2 root root 0 Aug 12 12:01 ../
drwxrwxrwx 2 root root 0 Aug 12 12:01 foo/
russ@DESKTOP-K1JHN54:~$ ll temp/foo/baz
total 12
drwxrwxrwx 2 root root 0 Aug 12 12:01 ./
drwxrwxrwx 2 root root 0 Aug 12 12:01 ../
drwxrwxrwx 2 root root 0 Aug 12 12:01 foo/
russ@DESKTOP-K1JHN54:~$

This is fixed on an internal build. Should hit an Insider build before too long:

russ@RUSSALEX-BOOK:~$ ln -s /mnt/c/Temp/ ~/temp
lrwxrwxrwx 1 russ russ 12 Aug 12 18:56 temp -> /mnt/c/Temp//
russ@RUSSALEX-BOOK:~$ ll temp/foo/
total 4
drwxrwxrwx 2 root root 0 Aug 12 18:55 ./
drwxrwxrwx 2 root root 0 Aug 12 18:55 ../
drwxrwxrwx 2 root root 0 Aug 12 18:55 bar/
-rwxrwxrwx 1 root root 0 Aug 12 18:55 bar.txt*
-rwxrwxrwx 1 root root 0 Aug 12 18:55 foo.txt*
russ@RUSSALEX-BOOK:~$ ll temp/foo/bar
total 0
drwxrwxrwx 2 root root 0 Aug 12 18:55 ./
drwxrwxrwx 2 root root 0 Aug 12 18:55 ../
-rwxrwxrwx 1 root root 0 Aug 12 18:55 baz.txt*
russ@RUSSALEX-BOOK:~$

[ranneyd]

@russalex

When testing I ran ln -s /mnt/c/tmp ~/temp instead of ln -s /mnt/c/tmp/ ~/temp. Forgot the all important '/' at the end of tmp.

Guess what. I did the OPPOSITE of this and it worked for me. Omitting the slash after tmp made it work flawlessly. Go figure.

[ssylvester87]

Hey, I'm glad I found that this is a known issue and a fix is already in the pipeline - I've been encountering it as well. I just wanted to make a quick comment that the workaround of removing the trailing slash is often not viable in situations where the symlink is in a Git repo that is cloned as a dependency of something else. (In my case, building Riak from source involves several dependency repos with symlinks in them.) If the makefile runs git clone to pull the repo, the Windows junction will be created and anything that subsequently attempts to traverse the directory structure will hit the infinite loop described in this issue.

Submitting a pull request to have the trailing slash removed in the Git repo would also not solve the problem if the program pulling it as a dependency is locked to a specific tag or version.

Thanks for giving this your attention! I've been really impressed with WLS so far. The little edge cases like this are definitely the exception rather than the rule.

[Dr-Irv]

According to https://msdn.microsoft.com/en-us/commandline/wsl/release_notes, this is fixed in Build 14905.

[linaori]

Any idea when this build will be rolled out? I'm on 14393.222 and I got this (big) update only yesterday.

[nutcasev15]

Hey Guys.
I'm on 143393.222. Trying to compile Binutils but it hangs indefinetly on checking dependancies.
Its is not necessarily a symlink error but it seems this is not fixed in here. Think this is related to #765 except here the terminal hangs checking if mv supports the trailing slash.

[russalex]

The team's focus is on providing new functionality and fixes to the Windows Insider builds. Only security updates and very select fixes will be pushed out through Windows Update to the 14393.x builds. We discuss this a bit on our WSDL blog here.

[russalex]

Cleaning up some old issues and this one looks to have gone out to the wild. Marking as closed now. Please re-open if things still show incorrectly on the insider builds.

[derekriemer]

Hi: This also seems to occur for directories with spaces in them.
I discovered it by trying to put a simlink to my google drive directory.
In my bashrc
WINUSR='/mnt/c/Users/derek_2'
if [[ ! -e ~/wd ]]; then ln -s $WINUSR wd; fi`
if [[ ! -e ~/gd ]]; then ln -s "$WINUSR/Google Drive" gd; fi

No / necessary

[bitcrazed]

RE-opening & assigning to @jackchammons for investigation/comment.

[jackchammons]

@derekriemer What version of windows are you running? Use the ver command in CMD.

[derekriemer]

Hey, This is fixed in creators (Now that I updated).

…

On Tue, May 2, 2017 at 3:58 PM, Jack Hammons ***@***.***> wrote: @derekriemer <https://github.com/derekriemer> What version of windows are you running? Use the ver command in CMD. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#650 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivcwuiDurAlRT5xJH_2U5HDzP3DDHks5r16cCgaJpZM4JLE78> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>