Live data from Hacker News

Windows for Linux Nerds

blog.jessfraz.com

91–100 of 393 posts

Re: Windows for Linux Nerds

#91
post #84

Earlier quoted context omitted.

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

Re: Windows for Linux Nerds

#92
post #84
post #82

Earlier quoted context omitted.

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.

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.

Re: Windows for Linux Nerds

#93

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.…

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.

Re: Windows for Linux Nerds

#94
post #91

Earlier quoted context omitted.

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%\l…

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.

Re: Windows for Linux Nerds

#96
post #62

Linux on Windows 10 seems like a good thing. I plan to use it for testing a Node.js application developed on Windows

You're probably going to have a bad time. Some of the lower-level network APIs are pretty buggy last time I checked.

We've made a lot of improvements in the last few months of insider builds. If there are still blocking issues, I'd definitely be interested in hearing about them.

Re: Windows for Linux Nerds

#99
post #93

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.…

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 f…

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.

Re: Windows for Linux Nerds

#100
post #93

Earlier quoted context omitted.

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 f…

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…

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.
Post reply on HN