> So basically "there is a gaping hole in the middle of the street but it's ok, I've put a 'road ends here' sign in front of it so now it's the drivers' fault if something happens"

What you're describing there is road works and yes of course it would be the drivers fault if they drove into the middle of the work. Even aside the obvious point about the work being sign posted, it's the drivers job to be vigilant of hazards - including those that aren't signposted (eg potholes).

> In this case this results in a lot of files not being editable by windows programs, plain and simple - such as the entirety of /etc and /home. That's a pretty bad situation.

Think about it more like using the right tools to edit the right job. You wouldn't blame Windows / Microsoft if someone screwed up their registry because they edited that binary blob in Notepad instead of Regedit. Equally if someone is clued up enough about Linux to install and use the Linux subsystem then it's reasonable enough to expect them to use Linux tools to modify the files on the Linux filesystem.

The metaphor is wrong. As a normal user you would never come into contact with these files. The "gaping hole" is actually in a fenced-off area with keep-out signs where nobody would wander in by accident.

But then, a "normal user" wouldn't use WSL. Developers and power users do.

I create a file in my WSL home directory, and want to edit it in Sublime. So I google "where is the WSL home directory stored" and get `%LOCALAPPDATA%\lxss`. I plug that into WIN+R, and get the files in explorer. At no point was I stopped or even warned.

The reason is clear. WSL is grafted on to Windows, and has low priority. The windows shell and filesystem teams are currently not working to improve integration from their side (at least not publicly visible).

The shell people could put up a banner in explorer, like you got in Program Files in previous windows versions, that you shouldn't edit these files (e.g. via desktop.ini). From the filesystem side, it should be possible to make the kernel know about WSL and prohibit writing to those files from windows.

WSL could also have been implemented with an image file, instead of individual files in `%LOCALAPPDATA%\lxss`. The reason they did it this way, I believe, was to keep open the possibility of future two-way-integration. But this would mean change-listeners not only in Linux land, but in Windows-land... which again would need deeper integration from other groups at MS. I suspect once WSL has proven itself a bit, they'll add full transparent two-way-integration, i.e. you'll be able to edit lxss files from windows one day.

"WSL is grafted on to Windows, and has low priority" - not sure the team of ~12+ of us would agree with you on that.

And how would the shell team put up a banner in Sublime?

If the kernel prevented these files from being written to, how would we install the distro in the first place?

Could, should, might, may. Yep, there are 100 ways in which some things could, and may yet, be done, but these choices were made for hundreds of sound reasons.

We're still working hard on WSL - lots of improvements in the pipe.

You say that, but I've seen a few too many people delete random system files because they didn't know what they were and needed space. Granted, they should've read the "keep out" signs and have only themselves to blame.

These files are hidden by default, so not only didn't they read the "keep out" signs, they tore them down and said "See? No sign." and then ran into the hole.

I guess at some point you can't protect people from themselves anymore. One might even argue that people who use WSL (especially in beta) would be tech-savvy enough to understand how it's implemented and works, but apparently not ...

Sure - it is not a good situation. To me it would have sounded perfectly reasonable to edit WSL files with a Windows editor. There could at least be some kind of __README_FIRST_BEFORE_DOING_ANYTHING_IN_THIS_DIRECTORY.TXT.

I just wanted to make clear that the parent comment is slightly hypberbolic.