Nodes symlink creates file instead of directory

[donaldpipowitch]

Update

This was previously reported as a Node-specific issue and an issue with directory names which contain a ".", but as it turned out it is more generic and can be reproduced by these steps:

$ cd /mnt/c/Users/foo
$ mkdir someotherdir
$ ln -s someotherdir someotherdirlnk # creates "Super Special™ WSL junctions" which are shown as files

Below is the original issue

This bug-tracker is monitored by developers and other technical types. We like detail! So please use this form and tell us, concisely but precisely, what's up. Please fill out ALL THE FIELDS!

If you have a feature request, please post to the UserVoice.

If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.

Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues. Instead, send dumps/traces to [email protected], referencing the GitHub bug number. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".

• Your Windows build number: (Type ver at a Windows Command Prompt) Microsoft Windows [Version 10.0.16299.192]

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

$ node -v
v9.4.0

$ node
>  require('fs').symlinkSync('/mnt/c/Users/foo/path-to-some-dir', '/mnt/c/Users/foo/foo.bar', 'file')
>  require('fs').symlinkSync('/mnt/c/Users/foo/path-to-some-dir', '/mnt/c/Users/foo/foo.bar2', 'dir')
>  require('fs').symlinkSync('/mnt/c/Users/foo/path-to-some-dir', '/mnt/c/Users/foo/foo.bar3', 'junction')

(Note: The third param is only for Windows and should not change Unbuntu behavior. This is true: It always creates a file, but it should create three directories instead.)

• What's wrong / what should be happening instead:

Wrong:
I have three files in /mnt/c/Users/foo all called foo with the file extensions bar, bar2 and bar3.

What should happen:
I have three directories in /mnt/c/Users/foo/path-to-some-file called foo.bar, foo.bar2 and foo.bar3.

• Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here)

TODO for me.

See our contributing instructions for assistance.

---

First noticed while using yarn: yarnpkg/yarn#5302

[therealkenc]

I tried your repro and it creates Windows junctions not files (regardless of third param, natch). This was on 17083 , but I don't think anything changed since 16299.

Simpler repro because you are going to find the strace just calling symlink(2).

$ mkdir /mnt/c/Users/you/somedir
$ ln -s /mnt/c/Users/you/somedir /mnt/c/Users/you/somedirlnk

The junctions are by-design. You are probably wanting #1475.

[donaldpipowitch]

Strange. It looks like even ln -s creates a file for me, not a junction:

$ mkdir /mnt/c/Users/you/somedir
$ ln -s /mnt/c/Users/you/somedir /mnt/c/Users/you/somedirlnk

This was on 17083, but I don't think anything changed since 16299.

This comment (#1475 (comment)) says "Windows Insider Build 17046 contains some improvements for symlink compatibility". Maybe I need this update. 🤔

strace for ln -s

$ strace ln -s src src2
execve("/bin/ln", ["ln", "-s", "src", "src2"], [/* 17 vars */]) = 0
brk(NULL)                               = 0x1dc4000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=36605, ...}) = 0
mmap(NULL, 36605, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffcf45f4000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffcf45f0000
mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffcf3e30000
mprotect(0x7ffcf3ff0000, 2097152, PROT_NONE) = 0
mmap(0x7ffcf41f0000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c0000) = 0x7ffcf41f0000
mmap(0x7ffcf41f6000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffcf41f6000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffcf45e0000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffcf45d0000
arch_prctl(ARCH_SET_FS, 0x7ffcf45e0700) = 0
mprotect(0x7ffcf41f0000, 16384, PROT_READ) = 0
mprotect(0x60c000, 4096, PROT_READ)     = 0
mprotect(0x7ffcf4425000, 4096, PROT_READ) = 0
munmap(0x7ffcf45f4000, 36605)           = 0
brk(NULL)                               = 0x1dc4000
brk(0x1de5000)                          = 0x1de5000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1668976, ...}) = 0
mmap(NULL, 1668976, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffcf4438000
close(3)                                = 0
stat("src2", 0x7fffce8d2940)            = -1 ENOENT (No such file or directory)
symlink("src", "src2")                  = 0
lseek(0, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++ 

[therealkenc]

Okay cool, it changed. But we're still looking at by-design (before and after), or dupe #1475 if you prefer, right?

[donaldpipowitch]

Hi again. I tested this now on the computer of a colleague which has the Insiders 17074 installed. When we run $ mkdir foo && ln -s foo bar there inside /mnt/c/Users/you the bar is also shown as a file inside the file explorer.

I'd expect the command to behave like >mklink /J C:\Users\you\bar C:\Users\you\foo (run inside cmd.exe - it looks like the arguments for mklink are in a switched order?):

I don't know if this is a dupe of #1475, because I have to say that I don't really understand what #1475 is about. The title and description are quite hard to understand for me. Probably a mix of not being familiar with Windows, file systems and being a non-native speaker. Sorry. So I added the screenshots, which probably makes it a little bit easier to illustrate my problem.

[therealkenc]

It looks like that for me in Explorer too. Ben or Sven will have to confirm, but I believe it is a Super Special™ WSL junction, which is just confusing Explorer. If you look at the file with dir in cmd.exe it is reported as a <JUNCTION>.

One thing you might try is turning on Developer Mode in you colleague's 17074. From the release notes it will use ntfs symlinks and will show as type .symlink in explorer and <SYMLINK> in cmd.exe. But note you have to use relative paths, which precludes using /mnt/c/.... Or at least that's what I am finding. Ie:

cd /mnt/c/Users/foo
mkdir someotherdir
ln -s someotherdir someotherdirlnk

I don't know if this is a dupe of #1475, because I have to say that I don't really understand what #1475 is about.

That's pretty fair assessment and it isn't your English 🙂. It was an open question.

[donaldpipowitch]

which is just confusing Explorer

Is the by design or will this be fixed in the future? How should other applications handle this? E.g. VS Code can't see some of my packages, because yarn link/npm link (or just yarn in workspace based projects) create these "Super Special™ WSL junctions".

One thing you might try is turning on Developer Mode in you colleague's 17074.

We'll try that. (But I think it was already enabled 🤔.)

Thank you for all the work and responses so far!

[therealkenc]

Is the by design or will this be fixed in the future?

I suppose you could call it by design (but not ideal) in 16299, but "better" since 17046, because creating NTFS symlinks (contrast WSL junctions) is now supported. Whether it will be "even better" in the future I can't tell you, except to say no one closed #1475.

We'll try that. (But I think it was already enabled 🤔.)

If you have Developer Mode enabled, you are probably seeing <JUNCTION> because you have a /mnt/c/Users/foo absolute path, not a foo path relative to a working directory. That threw me for a minute as well. This could be a problem if your absolute path came from deep down inside yarn. There is more discussion in #353 starting here. Hopefully you can get a definitive answer from the team on how "ln -s /mnt/c/Users/you/somedir /mnt/c/Users/you/somedirlnk" should behave (by design or otherwise).

[donaldpipowitch]

It seems to work if you have a recent Insiders version and developer mode activated. Thank you.

[MrBlenny]

Same for me - updated to Windows 10 Insider Preview build 17074 (from 16299) - now it works.

[mloskot]

AFAIU, the developer mode is no longer required (since mid 2017). Or, is it still required if I don't use

• Windows 10 Insider (Build >= 16215)
  but
• Windows 10 Version 1709 (Build 16299)

Could anyone clarify what Windows build or WSL version do I need to get this 'symlinks situation' fixed?

[therealkenc]

AFAIU, the developer mode is no longer required (since mid 2017)

Developer mode isn't required for WSL anymore. But it is (irritatingly) still required for symlinks AFAIU.

Yes, confusing.

[mloskot]

@therealkenc Got it. Thanks!

I switched off the Developer Mode, because it fires services occupying port 22 what is quite unhelpful for Targeting the Windows Subsystem for Linux from Visual Studio :-)

I'm going to switch the Developer Mode on and configure the WSL SSH to listen on different port.

[therealkenc]

because it fires services occupying port 22 what is quite unhelpful

Yeah, there is also some pithy commentary on that here just for ref. Bonne chance.

[mloskot]

@therealkenc

Don't go reinstalling Windows just yet;

Oh my, I wish I stumbled upon that earlier! ;-)

Back to serious, thanks a lot!

[thsyd]

Try running as sudo. Seemed to work for me (running without sudo did not)
sudo ln -s /mnt/c/XXXXX .
(Where XXXXX is the rest of my directory structure)

Windows 10 Enterprise built 16999
WSL with Ubuntu 16.04

[MrBlenny]

Unfortunately this has started happening to me again. It was fixed for me on a different computer with an older version of Insider preview.

Now:

• Windows 10 Insider Preview build 17682.1000
• Node v8.11.2 (installed in WSL)
• npm v6.1.0 (installed in WSL)

Running npm link creates a symlink which appears as a file instead of folder. The link itself seems to work in the WSL world. Doesn't work in windows.

[snooopcatt]

same here, I have two machines, problem is on both:

• Windows 10 1803, node 8.9.4, Ubuntu
• Windows 10 1809, node 8.9.4, Ubuntu

running ln -s /mnt/d/foo/bar /mnt/d/buz produces link accessible with WSL but inaccessible in windows explorer

[concerned3rdparty]

Trying to create symlink under a different directory than pwd also not working. I'm in developer mode.

ln -sf ./test/build/ artifacts works but these ones
ln -sf ./test/build/ ./randomdir/artifacts,
ln -sf ./test/build/ randomdir/artifacts ,
ln -sf ./test/build/ ../anotherrandomdir/artifacts
don't work

[mattoni]

I'm running into this issue with npm link, developers mode enabled. Has anyone come up with a workaround?