Case sensitivity policy now means WSL creates cursed files and directories

[mcclure]

My primary use case for WSL is to have access to UNIX convenience utilities, such as git and mercurial, while doing Windows development. Today I cloned a repository containing a Unity project to my Windows home directory (/c/mnt from WSL's perspective) using "hg clone" in WSL.

Unity printed this utterly strange error:

I did not see this error before the Windows 10 and WSL system updates delivered this week.

I checked Google and found this blog post:

https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/

It appears WSL is now by default creating directories with some sort of strange special property which causes those directories to be case-sensitive. The blog post claims that you can use "fsutil.exe file setCaseSensitiveInfo [path] disable" to reverse the curse, but when I attempt this I get "Error: The directory is not empty."

I think that this is a very user-unfriendly behavior. Before, WSL nicely interoperated with Windows files and applications. Now WSL has suddenly started silently peppering drives with files with a strange Linux nature which can and does break "normal" Windows applications. This special nature cannot be detected without the use of obscure command line utilities, and it does not appear to be possible (assuming a populated directory tree of cursed files) to reverse it.

My expected behavior, and how WSL seems (???) to have worked before this week, is that files in the "Linux partition" (/) have Linux behaviors, and files in the "Windows partition" (/mnt/c) have Windows behaviors. I think that a better default would be that files in / should default to case=on and files in /mnt/c should default to case=off. Someone who really needs to create case-sensitive files on the Windows partition can locate the blog post and change more easily than someone who just wants to make files Windows applications can read.

A comment attached to the blog post explains that wsl.conf can be used to set case=off globally, but there are two problems. First off, I am not clear whether this is what I want. If I set case=off in wsl.conf, does that mean I will be creating case-insensitive in the "linux partition" (/ not /mnt/c/?). The blog post, if it is to be the only documentation of this feature, should be clearer (the blog post says "use wsl.conf" but leaves it to a comment to explain how, and has a long diversion about "DrvFs" at the end but does not explain what DrvFs is). Second off, it appears wsl.conf requires rebooting the whole computer to take effect. A further expected behavior is that it should be possible to change the default directory case property on the fly, or for a single process or session, the same way I can call "umask" to change the default permissions for files. (If the default were non-disruptive I would care less about this though.)

My Windows build number is Microsoft Windows [Version 10.0.17134.137]. My apt-get upgrade on the WSL/Ubuntu side is up to date.

[therealkenc]

Interesting that Unity is now blocking the case sensitive folders. Thanks for posting that development.

My expected behavior, and how WSL seems (???) to have worked before this week

If you were on 17134 last week and are on 17134 this week, any educated guesses on what changed in between? I am guessing "Unity", but don't want to make assumptions.

A comment attached to the blog post explains that wsl.conf can be used to set case=off globally, but there are two problems. First off, I am not clear whether this is what I want.

Yeah, this is what you want. In fact now that's the default on Insiders 17704. But changing your WSL-side mount options won't help alone because your directories are cursed until you uncurse them.

That isn't straightforward. The blog you cite says use fsutil.exe, which is correct. But how one applies that recursively on your cursed tree isn't clear. How to find which folders are cursed isn't clear either, but you can usually guess.

Practical path forward for you is as follows. Your stuff lives in git/hg, thankfully. (1) Delete the directory outright (in Win32 or WSL doesn't matter), (2) then do the case=off raindance, and (3) then check out your code again. You should be fine. If not we can troubleshoot some more.

(If the default were non-disruptive I would care less about this though.)

Amen to that.

[mcclure]

"If you were on 17134 last week and are on 17134 this week—"

As noted in the issue, I was not on 17134 last week, I was on… something else. Windows 10 did one of its "big" updates two days ago and after the update completed WSL popped up a box to announce it was also doing an update.

"Practical path forward for you is as follows. Your stuff lives in git/hg, thankfully. (1) Delete the directory outright (in Win32 or WSL doesn't matter), (2) then do the case=off raindance, and (3) then check out your code again. You should be fine. If not we can troubleshoot some more."

I have done these steps and the problem is resolved locally, thanks.

If in a future Windows the default is case=off, then that sounds like the problem is averted for others as well.

[therealkenc]

As noted in the issue, I was not on 17134 last week

Apologies, I misinterpreted overlooked "system updates".

then that sounds like the problem is averted for others as well.

Only if (like you and me) you never actually mix case in a directory and could "care less". If you do then you're hooped and back to the rock and hard place of (rock) three-digit #101 or (hard place) Unity telling you your directory is cursed.

Glad you're whole though. Do much appreciate your post.

[mcclure]

It seems like primarily what you have here is a documentation/education problem. If I search "case sensitive wsl" I get two blog posts, the one linked above and a newer one. Both are a little confusing, and both seem to assume a certain amount of familiarity with the wsl internals. I don't know the wsl internals. I just know Linux.

It would also be obviously desirable if that case=on/case=off "default behavior for my process" could be changed without rebooting the whole computer…

[therealkenc]

It seems like primarily what you have here is a documentation/education problem.

Thumper's Rule prevents me from saying much to that.

It would also be obviously desirable if that case=on/case=off "default behavior for my process" could be changed without rebooting the whole computer…

Case=off isn't a process thing. It is a mount thing. Assuming you don't have any background processes running in WSL (like say dbus or tmux or sshd) and have closed all your console sessions, then the next "WSL instance" (the next console session after every process has exited) WSL should have picked up the mount -o case=off without a glorious reboot. Failing that, you can sudo umount /mnt/c and re-mount it manually.

Maybe that detail could be documented better. Or something. But that is pretty much how changing fstab in Real Linux works too (if say in some unforsaken parallel universe the mount option existed in Real Linux for ext2).

[therealkenc]

I went and quipped....

(if say in some unforsaken parallel universe the mount option existed in Real Linux for ext2).

As the (probably not a) Chinese curse goes, "may you live in interesting times". May 7th mainline 5.2 Linux kernel pull.

Add as a feature case-insensitive directories (the casefold feature) using Unicode 12.1. Also, the usual largish number of cleanups and bug fixes.

Got to buy a warmer jacket. Getting chilly down here.

[Frozenfire92]

This has been quite a frustrating change to learn is now the default (with no clear explanations on how to fix). I spent quite a bit of time googling, to finally end up here with the closest path to a solution.

Context

I've used WSL since it came out to use git while doing Unity development on windows directories. This has worked very well and I never had to think of anything, it just worked.

Recently I came back to this workflow after about ~year and it doesn't work anymore. I kept getting the same error as OP in Unity when trying to open a unity project that is in a directory cloned by WSL git (in windows FS).

I found the blog post Per-directory case sensitivity and WSL which seemed to be the issue, but didn't really clarify WHAT to do to make it work.

Some more context: my project is two parts (a web app, and a unity app), with the web app being node based (and best suited for linux dev) and unity being on windows. However these live in one monorepo in a structure like so

repo-name/
├── packages/
│   ├── unity/
│   ├── webapp/

Because of the issues of unity not working on here I started this project with just the webapp in the repo, and the Unity project locally in a different directory (until I could figure out this shenanigans and get it in git properly).

Whenever I tried to copy the unity project over I would run into issues of access permissions when unity tried to move around its temp files.

I then found this issue (and another blog post) which mentioned to set this in the file /etc/wsl.conf

[automount]
        options = "case=off"

After doing that, restarting, and trying the process again (copying the unity project into the git repo) I would then get the error OP mentioned The project is on case sensitive file system. Case sensitive file systems are not supported at the moment. Please move the project folder to a case insensitive file system.

So either the changes in wsl.conf isn't needed, or its only part of the solution

I then deleted the unity project from the git repo and tried (in administrator powershell) fsutil.exe file setCaseSensitiveInfo C:\Users\Frozenfire92\Documents\dev\myProject\packages\unity disable

I copied the unity project over, and it finally worked!

The desire

• Make this easier
• Make what you need to do to make it easy better documented

I suspect most people using a similar workflow to above want it to "just work" like it did originally. I'm not sure if what I did is the best path forward, or setting the registry key like in the blog post (that was next on my list if this didn't work). I think having something come officially from Microsoft will be beneficial as well (setting flags/registry keys you don't know about recommended from some random person on the internet isn't always settling). Please just make this easy again :)

[Frozenfire92]

I wanted to test cloning this repo afterwards to see if it was sustainable. I ran into The project is on case sensitive file system. Case sensitive file systems are not supported at the moment. Please move the project folder to a case insensitive file system. again, so I tried to run fsutil.exe on the cloned directory but was met with this error

Error: This directory contains entries whose names differ only in case.

To fix this I made a new directory, ran fsutil.exe on it, and then cloned the repo inside of it. I was then able to use both unity and the webapp happily.

I hope this helps someone in the future looking into this

Update:

I may have spoke too soon, it appears I'm getting the issues in unity where I can't interact with the directories or files and getting access denied around the temp directories

Update 2:

I have abandoned this in search of something simpler. I tried a windows git client (github's) and cloned it into a windows directory. I was able to properly use the webapp with WSL and unity was working properly.

[mcclure]

@Frozenfire92, I'm not totally sure I understand your problem, but I think maybe you have found something that you should file as a new issue. This issue (#3356) was due to a default that WSL had switched on for about a month in 2018, so if you are finding WSL creating folders as case sensitive, it is for a new reason and I think that's not supposed to happen.

Note that you should make sure, if you run git in WSL, to check out into the windows drive (/mnt/c) and not into the linux drive (eg ~/). My understanding (I am just a WSL user so I could be completely wrong) is that the Linux "partition" in WSL is not correctly readable by Windows apps, both because of case sensitivity and because the Linux "partition" has an independent file cache which may not have synced to disk by the time a Windows app tries to read it.

[durack1]

Just a warning folks, it seems that with the 19041.265 (and now .329) 2004 Win10 update this issue has reappeared again, with network shares no longer opening with the error "The file cannot be opened because the path has a case-sensitive directory". It seems that MS is aware of the problem, but I do hope the issue is resolved soon