Support for symlinks and long filenames in bash
Ubuntu subsystem on Windows blows my mind (being a Ruby dev using a Windows 10 machine). I tried many solutions and I've settled with a Vagrant Ubuntu combined with Unison to sync projects across the two machines. Would love to get rid of the vagrant instance but we need to ensure Ubuntu subsystem will support symlinks and extended filenames out of the box (esp since its using shared storage with Windows 10 core subsystem). NPM, for example, needs these two features before it'll work natively. Good work guys!
Josh S (Josh.5) commented
This is the first issue I face with my projects. My projects currently require symlinks to be pre-configured prior to compiling. I can see that symlinks work in the environment, but I'm talking about compiling 30GB of data. So Ideally I would like the project to sit on a separate hardisk to windows itself. Would it be a possibility to have ext4 support to this to mount an ext4 partition into this bash env? Or another option that comes to mind, could I move the whole bash env to my second (D:) drive so it is separate to the drive that has windows installed?
I want this feature so bad that if I could I would have allocated all my votes in favour of this.
current symlinks does not support for other filesystem.
Did I just see that symlinks are now supported on the Windows mounted drives in the new insider build? If that's true - this really is the sweetest news. No more unison to sync files between Windows drive and native Linux drive!
I don't think long filenames are a problem any longer. I actually have several repositories I could not checkout from git in Windows (using GitBash, actually), but bash has no problem :)
Per Lundberg commented
I agree with William's comment: GNU tar is broken without it (even on the Linux filesystem, I presume) so stuff like RVM cannot be installed.
William Guss commented
I am not sure if this has been mentioned but TAR is broken without proper symlink support at the moment. This needs a fix!
Joshua M. Pactor commented
Symlinks you create in the Linux FS can point into the Windows FS. For example:
ln -s /mnt/d/Users/joe/OneDrive/Documents /home/joe/Documents
will work entirely as you'd expect. Just tested and verified in the current release.
Nick Clark commented
Symlinks need to work, for sure!! If the goal is to help people use the same OS for work and leisure, the Linux subsystem will need to be able to build and run Linux programs reliably.
Symlinks are a big part of that, and can be common in build systems (even ones that might need to interact with Windows utilities!)
Denis Washington commented
Note that symlinks within the Linux part of the filesystem work just fine, but symlinks within the mounted Windows filesystems (or between the Linux and Windows filesystem) don't. See the Bash on Windows FAQ (https://msdn.microsoft.com/en-us/commandline/wsl/faq) and the related issue on GitHub (https://github.com/Microsoft/BashOnWindows/issues/6).