Hacker News Reader

Comment by SwellJoe | Hacker News Reader

I ran into this problem within days of starting to use Bash on Windows. Had several files just disappear, though I didn't need to reinstall anything (so far). They should really document this issue better, like in the docs for installing WSL.

View on HN

In fairness, as the author points out, the files are hidden and marked as "system". People tinkering with files flagged system are usually going to have a bad time. You have to specifically go digging for this, and then decide you want to mess with it.

Microsoft's platform design is generally open enough to allow you to do dumb things. This is a good thing, because you can reg-hack your way around problems with the OS. But like editing the registry, doing so is very much at your own peril, it's really not designed to be tampered with by users.

I don't think it's fair to blame people for thinking they could edit simple text files under that folder, well-hidden as it is. How many people already knew there would be any issues beyond line endings (not counting those who learned by breaking things)? I sure didn't. It's pure luck that I hadn't tried it yet.

It's absolutely fair. To even SEE these files, there's a warning you must click through that notifies you that you can cause significant harm to your system if you modify them. So when one does so, and then one modifies them... one should definitely expect to cause significant harm.

People who enable visibility on protected system files and then act upset that messing with protected system files breaks things, are the sort of reason we don't give out admin rights where I come from.

I don't think it's fair to be upset when editing those files breaks things, either. To be surprised? Yes, definitely. It is fair to expect software labeled "beta" to break in surprising ways, so I hope they're not giving permission to use WSL in production where you come from.

Hmm...none of that matches my experience. I opened them from Powershell or git bash and from Atom, maybe vim was involved. I don't remember the process of getting there, but I do remember it being tricky to find the directory where the Linux environment lived, but, maybe, a grep or find was involved. Windows Explorer was not involved.

I'm a 20+ year Linux user. I use Linux tools to find things and to navigate places. I guess if I were a Windows user, who does things in the usual Windows way, I might have received a warning of some sort.

I'm just saying it'd be cool if there were a warning somewhere in the docs about this issue. It wasn't something I expected. I mean, I don't have to worry about editing "Windows" files on my Linux system with WINE. And, I'm able to mount my Windows partition from Linux and edit files without fear of harming things. I assumed things worked the same way for WSL. It was a wrong assumption, but I don't feel like it means I'm stupid to have made it, based on the knowledge I had at the time.

> I'm just saying it'd be cool if there were a warning somewhere in the docs about this issue.

If you find any docs about this folder from Microsoft, you will find that they do warn you about exactly this.

"Interoperability between Windows applications and files in VolFs is not supported." -- Microsoft

I wasn't looking for docs on a folder, I was looking for docs about WSL (of which there were none other than the blog post about how to install and enable it, at the time). It's beta software, and I'm not complaining (my review of WSL at the time commented on this problem, without knowing it was a known issue, and I just said something to the effect of, "I won't do that again!" rather than "I'm gonna burn down Microsoft for doing this to me!").

It's no big deal, really. I didn't expect miracles, and it all works much better than I expected. I wish the interop were better, but I'm pleased it's even something Microsoft is trying to do.

That quote comes from here:

https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subs...

But I suspect they specifically wouldn't mention it because it's an implementation detail people aren't supposed to know about or look into. The problem might have been more widespread had they actually said "Don't change anything in this specific hard to find hidden/system protected folder"

Cool. I might have even read that at some point in the process and lacked enough understanding of the system to know what it meant. I found the process of getting WSL installed quite confusing, so maybe I was distracted. But, reading it even now, it doesn't jump out at me that using a Windows app to mess with Linux files would be disastrous (it was not disastrous for me, but had the files been important, it would have been, as they disappeared). It sounds like it's a thing that just wouldn't work;, e.g. Windows apps wouldn't see them at all, rather than it would potentially destroy your Linux installation, which is what this blog post indicates can happen.

Wouldn't your OS not being able to see files from a component on your computer be even worse?

"They should really document this issue better, like in the docs for installing WSL"

What, like this bit in the install instructions page: https://msdn.microsoft.com/en-us/commandline/wsl/install_gui...

After installation your Linux file system components will be located at: C:\Users\<Windows user name>\AppData\Local\lxss\ This directory is marked as a system file which are hidden by default. Accessing this location directly is not advised due to caching between the Linux and Windows file systems. Check out our blog post for more information.

same here, tried to modify some files in my windows IDE while using them from an apache on the linux subsystem - had to change the webserver directory to /mnt/c/...

Reply on news.ycombinator.com