Hacker News Reader

Comment by tootie | Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com