metadata allows us to have correct permissions, but saving a file overrides permissions back to 755

[nickjj]

• Your Windows build number: Version 10.0.17134.1 (Windows 10 Pro, Spring 2018 edition)

• What you're doing and what's happening:

1. Enable metadata in your /etc/wsl.conf
2. Go to one of your WSL mounted drives
3. touch hi.txt
4. chmod 644 hi.txt
5. stat -c "%a %n" hi.txt => 644 hi.txt
6. Open hi.txt in VSCode, make changes to the file and save it.

• What's wrong / what should be happening instead:

I would expect that hi.txt still has 644 permissions but if you run stat -c "%a %n" hi.txt you'll see that it returns 755 now instead.

It's like the metadata permissions are being stripped away.

• Thoughts:

Someone on Reddit says this is because VSCode forces safe writes which means a new file gets copied to a tmp directory which is to help prevent data loss.

However, VSCode has no option to disable this, so metadata is essentially not available since every file you edit will end up having it removed.

Is this something that can be fixed and patched into the stable version of Windows without having to wait 6+ months for the next big release?

[WSLUser]

This has to do with VS Code honoring permissions therefore is a VS Code actionable which already has an issue: https://github.com/Microsoft/vscode/issues/49021. I recommend adding your input there to help prioritize the work.

[nickjj]

Thanks, I didn't notice that open issue on the VSCode side of things.

[WSLUser]

Well you can run the Linux version of VS Code in the meantime if you like. That is, if you don't mind installing VcxSrv or Xming. If the permissions aren't a hard stop though, I'd just chmod it again after saving the changes.

[nickjj]

Yeah previously I ran Sublime Text through mobaxterm because prior to either 17.09 or 18.03 stable you couldn't run VSCode through WSL (along with other Electron apps).

Trying to avoid that now simply because it's nice having 1 editor that works on both sides and I run all of my code through Docker so I'm not really losing anything in terms of code complete (there's no support either way currently).

chmodding it afterwards is pretty brutal because in a typical web development session you might end up touching 30 files and it would be hard to keep track of that. Writing a script to chmod all files back to 644 might be dangerous too, since you could have legit executable files.

Hopefully it gets fixed on the nodejs side of things and then merged into VSCode shortly after.

[WSLUser]

Yep, that can get messy quickly. With the extended attributes, you should still be able to save to /mnt/c or whatever directory from Linux VSCode.

since you could have legit executable files.

I'd keep anything not legit in their own directory (the same directory for all non-legit), symlink them and run a script against that directory. But web development isn't my main area so maybe that isn't practical for you.

[therealkenc]

Trying to avoid that now simply because it's nice having 1 editor that works on both sides

One pretty common approach, which predates WSL by a decade or more with Samba shares and the like, is to just ignore it; especially if you spend a lot of time on the "Windows Side". On Windows, there sits all those .html files with the Windows exec bit set, and you never thought twice about it. The reason you don't think twice about it because cmd.exe dir doesn't draw the files in green. It doesn't matter that they're green in WSL/Linux.

Other way to go is to just use native Linux VS Code in WSL like DarkSpock says. It already "works on both sides", if there is such a thing. I'm betting your .html and .js files don't end in CRLF either (nevermind the file mode). Which can be worked around. So can Windows git. But why.

[nickjj]

I did have to configure VSCode to use "files.eol": "\n" to get beyond some CRLF related issues (especially with Docker entrypoint scripts).

You are right in that I could choose to ignore them. My main gripe isn't so much getting smacked in the face with a bunch of green text, it's every file I commit to version control ends up being tagged as executable. All of my recent repos on Github are filled with executable files that shouldn't be.

I extensively researched this and wasn't able to find any git setting that would get around that. I don't use Windows git, or really develop anything Windows specific.

99% of the time when I edit a file it's by running code . through ConEmu in a WSL mounted directory. Working on Docker powered web applications or Bash scripts / Ansible stuff.

The only semi-nice thing about having a VSCode Windows installation is having the right click context menu for editing a single file but I rarely use it.

One perk of going native WSL VSCode that I see so far is that you can now edit files like your ~/.bashrc within WSL's "real" file system using VSCode. The Windows version wouldn't open those files.

By the way if anyone is curious, the native WSL VSCode does respect permissions. The test case presented in this issue produces the expected result.

Kind of seems like a win for native WSL VSCode at this point? Permissions are correct, and you can edit native WSL files. Performance through X server feels as good as native Windows. I'm really picky about these things but I'm not noticing any extra input lag on key strokes.

[therealkenc]

it's every file I commit to version control ends up being tagged as executable

Yeah, in this "approach" you ignore that too. Consider, Microsoft has about 3.5 million lines of C/C++ code committed to their internal git repo with the exec bit set and CRLF EOL, and none of their 4000 programmers care. To be clear, it isn't how I roll. It isn't how you roll. I'm not saying go that way. But that doesn't change the nonpartisan observation that it doesn't matter.

By the way if anyone is curious, the native WSL VSCode does respect permissions. The test case presented in this issue produces the expected result.

Exactly. Because of course it does. 👍

[nickjj]

Fair enough. Do you think we should close this, or could this eventually make its way into WSL so that editing files within Windows won't mess with the metadata?

[therealkenc]

or could this eventually make its way into WSL

There's no WSL actionable. It would be like asking Linus Torvalds if it will make its way into the Linux kernel running in Docker with a C:\ share and Windows VS Code editing a file on the share. The feature needs to be implemented in Windows VS Code. As to closing, meh. Your poison.

[nickjj]

Are you ok with keeping it open for a bit to see if anyone else has an opinion, since it's labeled as discussion? If it dies out, I'll close it in a few days.

Thanks for the back / forth btw.

[therealkenc]

Sure. Plenty others where this one came from. Eventually they get closed (on no particular schedule) when the discussion dies out; or close it yourself whenever you want.

[therealkenc]

FWIW, the downside to doing everything in WSL is file performance. VS Code is slow to start up for this reason. Find in files and such also crawls. git is horrific if your repo is large enough. So, for example, I don't think anyone on the Office 365 webdev team is going to be using WSL as their go-to development platform. They're probably using Visual Studio and thinking nothing of your metadata grief. But it might work for your purposes. Bonne chance.

[nickjj]

Most projects I work on are under 50,000 lines of code and at most hundreds of files. Typical Ruby / Python / Elixir based web applications with a lot of HTML, CSS and JS mixed in.

Startup time in a project with 17,000 lines of code was about 500ms slower with native WSL if I just eyeball the speed. There's a noticeable delay before the window becomes visible but it's not a deal breaker.

That is good to know tho, I'm sure others work on much larger projects.

One of my main focuses is readability. I do notice the font looking a bit worse on native WSL VSCode (it's quite thin, a little blurry and looks like the AA is jacked up). Readability is important because I record video tutorials for developers. That's one more potential downside to native WSL VSCode.

[therealkenc]

I do notice the font looking a bit worse on native WSL VSCode (it's quite thin, a little blurry and looks like the AA is jacked up

You might try VcXsrv and make sure your have "native opengl" off (sic) and LIBGL_ALWAYS_INDIRECT not set (despite poor advice to the contrary). Don't run compiz, because that's crazy. I get results that look about the same as Real Ubuntu, at least to the naked eye on my standard HD rig. But we're treading dangerously into #637 territory, so I'll quit now while I'm ahead.

[fpqc]

@therealkenc I always wondered if MS could just add additional metadata caching directly to the read and write file functions in the Windows SDK. Right now, programs like sublime do cache the Windows permission bits, and I assume that is automatic, so I would also assume that they could also cache and rewrite the new LX data.

Why couldn't this work (so all programs compiled on the latest SDK would work)?

[Biswa96]

You can read and write that metadata with NtQueryEaFile and NtSetEaFile.

[therealkenc]

@fpqc - "Caching" has nothing to do with it. The problem is VS Code, via Electron, via Electron's NodeJS, via libuv has no idea how to set WSL's file and directory mode bits. If you look at the libuv code, it (obviously) doesn't set the mode bits on file creation. Because, there was no API to do so. The API is now, presumably, NtSetInformationFile() with FileStatLxInformation and struct _FILE_STAT_LX_INFORMATION. Presumably, because I haven't actually tried it.

Libuv could be updated to call NtSetInformationFile() if someone were motivated enough. There's a minor gap in that Windows has no process umask, but that could probably be hand waved. But just recompiling against a new SDK doesn't get you there, because said SDK has no idea what mode to give the new file or directory. On Linux, that's the third param of open() passed from userspace (here, that's libuv). CreateFile() knows of no such animal.

So you say, just have CreateFile() set some reasonable defaults. Okay. But that is, or at least should be, the umask/dmask/fmask you configure when you mount DrvFs. Just like ntfs-3g. The "reasonable default" MSFT has chosen for now is, as Nick discovered, 0755. There is nothing to recompile. You just don't like the defaults.

[therealkenc]

Are you ok with keeping it open for a bit to see if anyone else has an opinion, since it's labeled as discussion? If it dies out, I'll close it in a few days.

Pretty "ran course" at this point.

[mindplay-dk]

Team of PHP developers using PHP Storm here.

This is a huge problem for us - it's really hard to understand what the problem is, because we didn't use to have this problem with previous versions of WSL.

I use the Git integration in PHP Storm on Windows - and for that to work, I have to run a Windows version of Git for Storm, as well as a Linux version of Git for general use in the Linux console.

This combo worked just fine in early versions of WSL.

Then came this update where we had to manually enable metadata in the WSL config file - at this point, things started to break, but enabling metadata in the config file seemed to fix it.

Some time after that, another update must have been rolled out, because everything went to sh*t - I make a rule of always checking out in the Linux console, and usually, after that, there's been no problem, but since one of the last update, everything is completely messed up.

I'm either seeing all files as modified with git status on the Linux console - or seeing random files as modified in Storm, since the files have permissions that can't be applied to the Windows file-system.

Many developers don't notice the file permission changes and end up committing and pushing those - and I clone them on Windows, and half the files immediately appear to be changed, and there's no way to get them to appear as not changed.

I'm getting desperate. I have my entire work environment set up with WSL, as this was working beautifully for a long time. Suddenly there's an update and my whole work environment is trash.

I'm not Linux savvy, at all - I'm a programmer, not a sysadmin.

If there's any way to set up a WSL that worked as it did originally, please, can somebody provide step-by-step instructions?

Or should I just quit Windows and put up with an actual Ubuntu installation? 😭

[teras]

there's no way to get them to appear as not changed. I have exactly the same issue here ☹️

[thefallentree]

what is the conclusion here? Either we need an way to tell windows create file in 0644 mode , or we need to fix every IDE to properly detect metadata on NTFS files and know to preserve that when doing "write"

[herrvigg]

@mindplay-dk wrote:

This is a huge problem for us - it's really hard to understand what the problem is, because we didn't use to have this problem with previous versions of WSL.

Same here, i used to have something working nicely by editing in Windows and pushing to real Linux systems but now it's become a complete chaos with the file permissions. It seems it worked fine when everything was owned by root in WSL but i can't really remember how the permissions were set. In any case it has become worse now (from this?) and even if i mount the windows drives without metadata the problem is not solved 😭

[mindplay-dk]

In any case it has become worse now (from this?)

Possible.

From this article:

For files that don’t have metadata, we apply the same approach as what is described in pre-17063 builds. ... Once the file or folder has metadata, Windows and Linux permissions will not remain in lock-step with each other.

Perhaps the mistake was enabling the metadata feature?

As I recall, I started having problems before the metadata feature was introduced - and it seemed like enabling metadata solved those problems for a while, and then later it all went south.

I'd be fine with a single owner of everything - I'm obviously only using the Linux thing for local development and don't plan on running a public Linux web-server from under Windows. (Does anyone?)

[jonreeve]

Bit of a dead thread to post I know but since it doesn't look like there was a great answer for people working with git projects under WSL, I would suggest git config core.filemode false to tell git to ignore that executable bit flip-flopping, and just see it as unchanged. You can of course toggle this off again if you want to specifically set it, then turn it back on. Helps me keep some of my sanity with IntelliJ IDEA and WSL 😜

[Sieboldianus]

Bit of a dead thread to post I know but since it doesn't look like there was a great answer for people working with git projects under WSL, I would suggest git config core.filemode false to tell git to ignore that executable bit flip-flopping, and just see it as unchanged. You can of course toggle this off again if you want to specifically set it, then turn it back on. Helps me keep some of my sanity with IntelliJ IDEA and WSL 😜

Sadly, this needs to be done for every repository manually, which is a pain. Also, --global does not work since git init and clone override what is set in clone for core.filemode see 1

[gerardbosch]

Sadly, this needs to be done for every repository manually, which is a pain. Also, --global does not work since git init and clone override what is set in clone for core.filemode see 1

You can add a git alias for clone and init and use it from now on to newly cloned repos: .gitconfig:

[alias]
    cl = clone --config core.filemode=false
    in = init --config core.filemode=false

Just use git cl from now on in Windows.