Make it more obvious that Windows programs shouldn't touch WSL partition

[steveklabnik]

This is mostly a request for better docs. I understand why this behavior happened, but it could have been prevented if I had known this to be true.

I've been using BashOnWindows as a primary development environment for a while now. I've also been trying to migrate from vim to VS: Code. So today, I thought "hey, I should work with Code instead of vim." That's all good, but when I opened up my projects, which live on my BashOnWindows partition, I got an error with git. After looking into things, it looked like my partition was now full, which seemed very strange since it was working a few minutes before.

After talking with some people about my issues, they said "oh yeah, you can't have a windows program touch your BashOnWindows partition or it hoses it."

I'm not upset that this happened (though it is going to pretty much kill the rest of my workday to get my environment set up again), but it is unfortunate that I didn't know this was something I wasn't supposed to do. I re-read the documentation for BashOnWindows to make sure I didn't miss anything, but I didn't find anything.

Was this something I should have been aware of? If so, how was I supposed to be made aware of it?

Thanks so much for BashOnWindows; other than this, it's been working very well for me, and I have been evangelizing it to my friends for a while now. 😄

[sunilmut]

@bitcrazed who has documented this and advertised it as well. He can point to you various documentation sources. Independent of that, we understand that this is a serious limitation and are looking into improving the integration story here. Thanks for using WSL and providing feedback. We really appreciate it.

[aseering]

For what it's worth, I think the current expectation is as follows: The WSL directory (technically on the Windows side it's a directory rather than a partition) is not visible with default settings. You have to configure Windows Explorer to make hidden system folders visible. The standard user documentation doesn't generally cover how that feature's hidden system folders are structured and what is and is not ok to do with them. For that, you have to read documentation that covers the architecture / implementation of the feature. For example:

https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/

That said, more docs are always good :-)

[aseering]

Oh -- hi @sunilmut @benhillis ! Listen to them; they actually work on WSL :-)

[therealkenc]

To the extent anyone wants to even entertain this apparently touchy subject, it would be nice if the WSL kernel did something other than halt and catch fire here. Yes, the extended attributes got blown away by win32, but that doesn't have to be fatal. If the attributes aren't there, branch and set (or treat) the attributes to (as) 0400 and user/group 0:0. At least then the recovery process becomes: "log into bash and fix it with chmod and chown", rather than "delete everything and start over". You can make a straw man argument about named pipes or unix sockets, but frankly that isn't the bug here.

First rule of programming: Don't delete people's data. I understand that a grand fix is in the plan, but in the meantime, at least being graceful in the face of failure would be a good place to start.

[sunilmut]

Adding @SvenGroot who has studied this in depth.

[steveklabnik]

@aseering

The WSL directory (technically on the Windows side it's a directory rather than a partition) is not visible with default settings. You have to configure Windows Explorer to make hidden system folders visible.

I typed the path directly into an "open" dialog box, so it at least lets you do it that way as well.

[SRGOM]

I agree with steve- end users are not likely to read up 100 pages of documentation- specially because WSL actually "just works" so it's hard to stop marveling.

[steveklabnik]

specially because WSL actually "just works" so it's hard to stop marveling.

Yes, ironically, it was probably that it's so awesome that I expected this to Just Work in the first place, heh.

[tucker973]

I've found symlinking can be a very useful way to work around this issue. While it won't help modify WSL system files, it does help things behave. Here's a simple example from my stack:
-Working sites I'm developing are in c:\Sites
-Symlink working directory to home, ~/Sites (aka /users/{me}/Sites)
-Caveat: Apache doesn't seem to like using a symlink, so virtual hosts must point to /mnt/c/Sites/{project}
-???
-Profit

So I can edit all day in VS Code, version control with git at ~/Sites/{project}, and it works wonderfully. I run node, Grunt, the works, with no issues using the symlinked path. However, as I pointed out above, the only quirk I've found is that Apache wants the "real" path in vhosts, but that's something I have no problem living with as everything else works smoothly.

[MikeGitb]

One thing I'm wondering is why people expect this to work in the first place. Have you considered to somehow obfuscate the file&folder names that reside in the lxss folder? Or simply place a text file there with the name "DON'T_MODIFY_ANY_FILES.txt" (should of course be invisible to the linux system) that contains the explanation.

[rodrymbo]

Remember that this is early beta software, so things should be expected to fail.

Tar does a fine job making a backup of the special lxss filesystem, assuming you do it from within the bash.exe environment and store the resulting tar/tgz file somewhere under /mnt. Restores everything pretty quickly if you have to delete the special filesystem and reinstall.

[therealkenc]

Remember that this is early beta software

WSL exited beta.

Perhaps someone with the power to do so could add a three liner to the faq so this issue can be closed out its undead state. It isn't really "tag discussion" thing. It is a straightforward docs ask.

[therealkenc]

Per OP, this is apparently as documented as it is going to get. Further documentation requests can be made like this.

[bitcrazed]

FWIW, we added the following to the FAQ some time ago:

One of the main limitations of using WSL is that changing Linux files with a Windows app or tool is not allowed. See: Do not change Linux files using Windows apps and tools

That said, I'll make a few minor improvements to the FAQ to make this clearer.

Also, since WSL exited beta, and distro's are now installed as store-packages, the Linux filesystem contents are even more difficult to find.

Hint: If you have to spelunk deep into hidden/obscure/protected filesystem folders, assume that anything you change could corrupt your environment/machine.

[therealkenc]

That said, I'll make a few minor improvements to the FAQ to make this clearer.

Bonus points if you use the adverb "accessing" rather than "changing". People are under the misimpression that accessing files read-only on lxfs is a supported scenario, and then come here to complain when their s*** don't work. [If in the alternative you want to call accessing the lxfs files read-only a supported scenario, cool, but then that presupposes someone replying when said issues are opened rather than leaving them chirp.]

Also, since WSL exited beta, and distro's are now installed as store-packages, the Linux filesystem contents are even more difficult to find.

True but that's a bug not a feature, and people are going to find it anyway with the most trivial of google searches. Not to mention other unsupported scenarios people seem to feel inclined to post here, where their distro tree lives right where they put it.

[bitcrazed]

Like minds ;)

https://github.com/MicrosoftDocs/WSL/pull/262/files#diff-09c4c1e4e39fa20bb4cd58616302b2f2R82