Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

If you need to access files in VolFS, you can use bash.exe to copy them somewhere under /mnt/c, use Windows to do whatever on it, then use bash.exe to copy them back when you are done.

IMHO this is the worst-designed(?) part of the whole WSL. Copying files back and forth is the antithesis of a "seamless Windows and Linux experience", to put it mildly. From that perspective it's no better than running an isolated VM. To add insult to injury, although I haven't personally tried it, apparently trying to access the files directly from Windows as if they were both on the same filesystem (which they are) results in all sorts of ridiculous breakage: https://news.ycombinator.com/item?id=12980380

I have mounted CIFS/SMB shares from Windows machines onto Linuxes and Macs, and gone in the opposite direction with Samba; in both of these cases, there is no need for wasteful copying and managing two files; Windows and Linux can essentially use the same files simultaneously.

Going in the other direction, WINE also allows Windows apps to work directly with the same files as Linux ones.

One then wonders, when a networked filesystem with all its complexity can be used nearly effortlessly across different OSes running on completely different machines, and WINE is like the inverse of WSL, why couldn't Microsoft do the same with two subsystems on the same machine using the same filesystem!?

I'm sorry that we don't provide a way to access the Linux portion of the file system directly from Windows yet. It's annoying, and we are working to improve it.

For many use cases it suffices to symlink a Windows directory (e.g. /mnt/c/Users/myuser) into your WSL $HOME directory somewhere and do your source work, builds, etc. in that path. This breaks down if you need certain features that aren't supported on these files yet (e.g. chmod), though.

I assure you that we find this annoying too and are working toward a better solution.

I think OP was being needlessly rude, it really isn't that painful. And to claim that network filesystems work seemlessly is laughable in my opinion. Though they are right, it does break the continuity a Linux subsystem in Windows could provide.

It blows my mind that Windows engineers are building (and keeping up-to-date) an entire Linux compatible subsystem. That's a huge investment, and a pile of hairy legacy code if the project should ever die.

BlackBerry worked on running Linux binaries on QNX for quite a while before coming out with Android application support in BB10. Microsoft could be looking to do something similar.

WSL was the result of Microsoft looking to run Android apps in Windows Mobile. Eventually they dropped the effort, and rescue it to execute docker containers on Windows.

Network filesystems are not perfect but they sure try very hard in a far more challenging environment than two subsystems on the same machine to give a "unified" access to the filesystem.

It blows my mind that Windows engineers are building (and keeping up-to-date) an entire Linux compatible subsystem. That's a huge investment, and a pile of hairy legacy code if the project should ever die.

Considering that multiple efforts by others[1][2][3][4][5], some of them working alone, have gotten quite far in running Linux binaries on Windows without any of the deep knowledge of Windows internals that Microsoft would have, maybe it's not all that huge of an investment... then again, the edge-cases are the hard part and MS does tend to like overcomplicating things.

[1] https://github.com/wishstudio/flinux

[2] https://cowlark.com/lbw/

[3] https://github.com/hackpascal/line-is-not-emulator

[4] http://wezfurlong.org/blog/2004/jan/linux-on-windows/

[5] https://0xef.wordpress.com/2012/11/17/emulate-linux-system-c...

I know this probably goes well beyond the scope of your department but here is my wishlist that would convince me to buy windows:

1. Support for ZFS (and future open source filesystems as they appear)

2. The ability to control every service running, and good honest descriptions of what each service does. The ability to control all the servers my computer is connecting to and a transparent view of the information they are sending

3. Ability to turn off having to use Microsoft Accounts, store, etc. Leave it on by default to make your money but offer a developer version/option.

What do you use now?

win7 & debian. I don't ever plan on going to win10, so my next computer will be full linux.

Shh don't tell them about ZFS. That's FreeBSD's killer feature!

#3 is already available, and always has been. I personally create a non-MS local account when I first install the OS, and then convert it to my MS account to get the features I want from that. I do this to make sure my user account has the name I want it to have.

> For many use cases it suffices to symlink a Windows directory (e.g. /mnt/c/Users/myuser) into your WSL $HOME directory somewhere and do your source work

that's what I'm doing for quite a while now and works well for my workload: fast IDE on Windows 10 for coding, reasonably fast building on WSL side.

sure, file access in WSL is slower that native, but still way faster than any other combination I've tried in the last few years (VM + Shared Folders, VM + SMB, VM + file sync, ...) when lots of files are changed at once, for example when switching between project branches.

I'm not sure what she is talking about because you definitely do not have to copy files across. I have a git checkout on my C: drive and interact with it via /mnt/c with no trouble. I'm editing in VS Code and running git and npm in Ubuntu shell with zero friction.

Soon you will have problems. She is right.

What is the problems? I have been doing this for one year without issues.

From https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...

Therefore, be sure to follow these two rules in order to avoid losing files, and/or corrupting your data:

DO store files in your Windows filesystem that you want to create/modify using Windows tools AND Linux tools

DO NOT create / modify Linux files from Windows apps, tools, scripts or consoles

Remember: There's a reason we gave the %localappdata%\lxss\ folder 'hidden' & 'system' attributes

That's talking about manipulating files in the LXSS filesystem from Windows tools. There's no problem with doing everything on your Windows mounts, assuming you don't mind everything getting +x.

The parent is storing files on the "Windows" part of the filesystem and accessing them from WSL, while my post (and https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n... which it indirectly links to) refers to storing files on the "Linux" part of the filesystem and accessing them from Windows (apparently some files must be in the Linux part, like certain configuration files etc.)

Incidentally, the response from a MSFT employee about why this isn't a problem with Samba is "Because this isn’t a supported mechanism for accessing files via a networked file access protocol; it’s what happens when a hacker modifies files stored in a hidden system folder.", which is pretty much a non-answer and almost a "you're doing it wrong" accusation in an attempt to hide from the fact that they seriously screwed this up.

Try mving a directory under /mnt/c from WSL. It won't work.

I have never encountered a file or directory there that I couldn't manipulate, can you give a specific example?

The limitation I know is that you are not supposed to touch the subdirectory that contains the Linux' filesystem root with windows tools, because that'll mess up some kind of hidden metadata.

I have a git checkout that exhibits this behavior but now I can't replicate it. If I clone another copy, I can mv directories but the file permissions are exactly the same.

Can you, for example, do os.rename to replace an already existing file with another one? That works on Linux, but chokes up on Windows as far as I remember. I wonder how does WSL handle that.

Me too. It was one of the reasons I came back to windows, but it proved useless. Sure I've just discovered it after having a corrupted filesystem.

I dreamed to edit a movie in a video editor, pass a filter using ffmpeg, but can't even edit a file in notepad and run it in Python.

VMs or remote access are still the best solution for development. Even cygwin and using setup.exe to edit files are better.

Huh? You just have to be careful not to use the linux filesystem from windows. It's hidden under %localappdata%\lxss anywax.

Editing test.py in your Desktop and then running it with python /mnt/c/Users/Neves/Desktop/test.py should work fine. I honestly do not understand your problem here. If you need to access a file from windows and linux, it must be in the windows fs. That's it.

Agreed, I do Ruby development like this and it is seemless. The code, editor and git live on Windows while Ruby and MySQL run on wsl.

Yes. If I had to figure it out by myself, not having read in an authoritative source that this is the way it's meant to work, I would assume I'm doing something wrong.

That sounds EXACTLY how I used to cheat at Nethack to create a saved game when I was a kid with a .bat file that would drop out of a game of nethack, then copy the game file to a .bak file. then I could go back into the into the game and not worry about dying - and I had the keystrokes down to where I could do them blind and effectively save my game in 5 seconds any time I wanted and be back playing. I was 10 years old.

it's clearly listed under "- pain points" with "still in its beginnings" so be gentle.

Reply on news.ycombinator.com