symlinkJoin doesn't work on WSL

[woehr]

Build 16257

Nixpkgs ghcWithPackages fails because symlinkJoin doesn't work. See https://github.com/NixOS/nixpkgs/issues/26506

To reproduce, install nix, then using nix try to install ghc with packages. For example:

• curl https://nixos.org/nix/install | sh
• echo "{}: {foo=(import {}).haskellPackages.ghcWithPackages (h: [h.text]);}" > foo.nix
• nix-env -f foo.nix -i -A foo

The following errors are produced:

installing ‘ghc-8.0.2-with-packages’
these derivations will be built:
  /nix/store/b8vq8x4zf7064k03br4arzwxq17q9ccn-ghc-8.0.2-with-packages.drv
building path(s) ‘/nix/store/6ngxwi2xpnzcivvkwiy78cjg09r9f1mc-ghc-8.0.2-with-packages’
.: File exists
..: File exists
.: File exists
..: File exists
lib: /nix/store/gyw8sz9pmg34hpwxs5rz1g90q8fvia3q-text-1.2.2.1/lib
share: /nix/store/gyw8sz9pmg34hpwxs5rz1g90q8fvia3q-text-1.2.2.1/share
rm: cannot remove '/nix/store/6ngxwi2xpnzcivvkwiy78cjg09r9f1mc-ghc-8.0.2-with-packages/bin/ghc': Permission denied
builder for ‘/nix/store/b8vq8x4zf7064k03br4arzwxq17q9ccn-ghc-8.0.2-with-packages.drv’ failed with exit code 1
error: build of ‘/nix/store/b8vq8x4zf7064k03br4arzwxq17q9ccn-ghc-8.0.2-with-packages.drv’ failed

[therealkenc]

I'm not about to install NixOS, but this is almost certainly #2229. Right now that issue is EWONTFIX. Which will have to be revisited eventually.

[pierrebeaucamp]

This bug is blocking me from effectively developing Haskell using Nix. (I'm on Build 16251)

[sunilmut]

I can't seem to find a reliable definition of what st_nlink means for a directory (if there is one, please share). The general words seem to suggest that the value can be relied only when > 1.

As @SvenGroot suggests in #2229, would it make sense to update LNDIR to take the sub-optimal path when the value of st_nlink is < 2?

[therealkenc]

[with heavy edits for improved "reliability"]

The "reliable" definition is that it is the number of hard links to that directory inode. For a directory with one subdirectory, that number is three. One, for the directory name (dentry) itself, say 'foo/'. One, for the './' dentry alias of the inode. And one, for the '../' dentry alias of the inode in the sub-directory. If the 'foo/' directory inode has two subdirectories, then there are two '../' dentries aliases for the that inode, for a total of 4. And so on.

When people say directory 'foo/' will have a st_nlink of at least 2 because of './' and '../' they're technically not correct. It is at least 2 because of 'foo/' and './'.

Also check out this post from the Cygwin people (from 2008). You've tried 2. You've tried 0. I think maybe the number you are looking for is 1. I just checked out ntfs-3g's behaviour and that's the number they use too. Whether that works or not, at least you'll be in good company.

[sunilmut]

@therealkenc - thanks for the explanation. I don't really see why 1 needs to be differentiated from 0, when both say the same thing "don't trust me". But, maybe, historically, some tools have differentiated these for whatever reason. I did a quick search for the source code for lndir, and if the source here is to be trusted, it looks like changing to 1 won't help.

[therealkenc]

Yeah, that looks about right. The only semi-constructive thing I could say would be making it '1' would make it bug-compatible with ntfs-3g. Would that make any practical difference on existing code? No, probably not. In the other issue I just gave a thumbs up without really understanding the full scope of the problem. Having finally caught up with where Sven has been all along, yeah, I see the dilemma. It would take a really big hammer to fix this.

[sunilmut]

It's cheaper to fix the tools to handle values < 2, than trying to come up with a value in WSL that satisfies all the tools. So, if someone is feeling up for it, we would recommend getting these tools "fixed".

[therealkenc]

Repurposing as a feature request to make the behavior bug-compatible with ntfs-3g. [Which can be declined at some future date without prejudice.]

edit: The st_nlink might even be 1 with 9p, I didn't look.