Case-sensitive directories inaccessible from remote machines

[github-cygwin]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  file server: 10.0.17763.316, WSL enabled
  remote client: 10.0.14393, no WSL

• What you're doing and what's happening:
  I'm the project lead of Cygwin. The idea to enable case-sensitive directories
  by default in Cygwin, as long as WSL is installed, had a certain ring to it.

Unfortunately I now found that accessing case-sensitive directories from
other Windows clients over the network results in very strange behaviour.

These observations occur on the SMB client which has no idea what WSL
or, FWIW, case-sensitive dirs are:

• In CMD or Explorer, listing the case-sensitive directories works at first. After
  opening a file inside such a dir, which works the first time, the directory
  disappears. After a couple of minutes, the directory appears again, but
  not necessarily the files in that dir.

• After pressing F5 in Explorer, there's a good chance the following dialog appears:

  \\server\path is unavailable. If the location is on this PC, make sure [etc, etc].
  If the location is on a network, [yada yada]. If the location still can't be
  found, it might have been moved or deleted.

• Checking what goes on by debugging a Cygwin process, I observe the following:

      status = NtCreateFile (&h,
                             READ_CONTROL | FILE_READ_ATTRIBUTES | FILE_READ_EA,
                             &attr, &io, NULL, 0, FILE_SHARE_VALID_FLAGS,
                             FILE_OPEN,
                             FILE_OPEN_REPARSE_POINT
                             | FILE_OPEN_FOR_BACKUP_INTENT,
                             eabuf, easize);

returns with STATUS_OBJECT_NAME_NOT_FOUND, on files inside the case-sensitive
dir, as well as on the directory itself.

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

  Well, I think that's obvious. It's kind of weird that SMB operations from a remote
  machine fail this badly on a case-sensitive directory. It's ok if the operations inside
  that dir from the remote machine are case-insensitive. But existence and opening
  of dirs and files inside of a case-sensitive dir from a case-insensitive client should
  still work, just the same as if the server has set
  HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive
  to 0, no?

Thanks for considering,
Corinna

[github-cygwin]

Addendum:

• You don't need files only differing by case to observe the above behaviour.

• If a process tries to reopen a case-insensitive CWD after accessing a file in
  that dir, the subsequent NtOpenFile fails with STATUS_OBJECT_NAME_INVALID.

[Biswa96]

Out of curiosity, could you provide a sample code to test? Does that issue occur in same machine?

[github-cygwin]

What do mean with asking "Does that issue occur in same machine?"

This occurs on a remote machine, this is not a local issue.

[github-cygwin]

I'm a bit puzzled about the request for sample code. You don't need specific code to reproduce the issue. Simple testcase:

• On the WSL-enabled Windows 10 machine, create case-sensitive directories in the normal Windows tree, e.g., right below C:\Users\yourusername. You can do this with Linux under WSL or with the most current Cygwin 3.0.1, like this:
  $ mkdir -p dir1/dir2
$ cd dir1/dir2
$ echo foo > foo
$ echo bar > bar

Switch to the remote machine, a 2016 Server in my case, open an Explorer Window and open the aforementioned directory, e.g., "\\w10wslmachine\c$\Users\yourusername\dir1\dir2", press F5 to refresh. There's a good chance that this fails with the aforementiond dialog.

Another way to reproduce this is with CMD and the command dir and type.

Using Sysinternals Procmon, you can see "CreateFile" fail with "NAME NOT FOUND"

[github-cygwin]

ping?

[github-cygwin]

Sorry if I'm persistent, but that sounds like a bug to me. Is there really no interest in this issue from the developer side?

[therealkenc]

n.b. I'm not a MSFT dev.

The idea to enable case-sensitive directories by default in Cygwin, as long as WSL is installed, had a certain ring to it.

It kinda doesn't. That ringing you hear is the kind that happens when you've hit your head. The per-directory case sensitivity directory flag was turned off in WSL by default as of 17704 (circa June 2018). So it wouldn't make a whole lot of sense to turn it on in Cygwin unless or until WSL turns it back on. I use the term "by default" loosely in the context. In practice it is off, because turning it on breaks things.

Is there really no interest in this issue from the developer side?

Observationally, based on historic evidence, just because there is no response immediately doesn't mean there is no interest. But repeat pings are a pretty good way to kill a thread. YRMV.

[github-cygwin]

n.b. I'm not a MSFT dev.

The idea to enable case-sensitive directories by default in Cygwin, as long as WSL is installed, had a certain ring to it.

It kinda doesn't. That ringing you hear is the kind that happens when you've hit your head.

Is there a reason for impoliteness?

The per-directory case sensitivity directory flag was turned off in WSL by default as of 17704 (circa June 2018). So it wouldn't make a whole lot of sense to turn it on in Cygwin unless or until WSL turns it back on.

The defaults don't matter. If WSL is installed, I can easily, explicitely, create case-sensitive directories anywhere I want on NTFS by calling NtSetInformationFile(dir, ..., FileCaseSensitiveInformation). Unfortunately I only tested this locally and forgot to test remote access, so I enabled this in Cygwin for mkdir(2) of directories inside the Cygwin installation tree (not for all dirs on the filesystem). I switched it off in the meantime after discovering the issue I described here.

Is there really no interest in this issue from the developer side?

Observationally, based on historic evidence, just because there is no response immediately doesn't mean there is no interest. But repeat pings are a pretty good way to kill a thread. YRMV.

From developer to developer I was expecting just a "confirmed" or something, not an immediate solution.

Corinna

[github-cygwin]

FTR:
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=4021509ba28e7
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=379598dd672d6

[therealkenc]

Is there a reason for impoliteness?

None intended. I am sure your multiple pings were not intended as impolite either.

From developer to developer I was expecting just a "confirmed" or something

You've already confirmed the behavior. Generally speaking, if the behavior is known to work then someone (sometimes me) will follow up trying to help the submitter though their problem. Here, it was abundantly clear you know what you are doing so there wasn't really anything to add. One of mine sat 7 months before there was a response for the same reason, and will celebrate a third birthday later this year. If an issue is open, it is still in play. If the issue is popular the "broken for me too" posts and the dupes largely speak for themselves.

[chrisjbreisch]

This is a rather annoying (and surprising) bug. I ran into it myself, foolishly trying to cross build an older version of glibc, which requires a case-sensitive filesystem. (I think 2.27 on do not have this requirement, but I was building 2.25). I ran into issues, and was sharing my filesystem with another, who duplicated Corinna's issue perfectly.

[atomsmith]

I recently tripped across this behavior as well. It may not originate in WSL at all. I was clued in by this blog that it's not necessary to install WSL to enable the case-sensitive folder feature: just add a DWORD key "NtfsEnableDirCaseSensitivity" set to 1 at HKLM\SYSTEM\CurrentControlSet\Control\FileSystem.

I found that Windows 10 ver. 2004 clients trying to read a remote case-sensitive folder will now report "The file cannot be opened because the path has a case-sensitive directory." It's nice that the error is so explicit. But it also suggests a fix might not be coming quickly.

[github-cygwin]

I found that Windows 10 ver. 2004 clients trying to read a remote case-sensitive folder will now report "The file cannot be opened because the path has a case-sensitive directory." It's nice that the error is so explicit. But it also suggests a fix might not be coming quickly.

I fear this is meant to be the fix...

[crmabs]

When a case sensitive shared folder gets opened from within windows it produces the error mentioned by @github-cygwin .
But mounting it from a remote machine with cifs works. Nothing special, default cifs network share mounting was used.
Maybe it helps.

I found that Windows 10 ver. 2004 clients trying to read a remote case-sensitive folder will now report "The file cannot be opened because the path has a case-sensitive directory." It's nice that the error is so explicit. But it also suggests a fix might not be coming quickly.

I fear this is meant to be the fix...

[ioweb-gr]

I really hope this will get fixed soon. I just bumped into this issue today when suddenly my shared folders became inaccessible through windows systems.

[crmabs]

well, now I remember bumping into this.
"What a cool thing! The directories I'm mounting from Linux are going to behave like their native brothers! Yay!"
"Oh, inaccessible shares?? W@t?"
And the worst part was the few circles I ran around while figuring it out.

[ioweb-gr]

When a case sensitive shared folder gets opened from within windows it produces the error mentioned by @github-cygwin .
But mounting it from a remote machine with cifs works. Nothing special, default cifs network share mounting was used.
Maybe it helps.

Just gave it a try to mount from my linux box and it doesn't really work either.

[eternalphane]

But mounting it from a remote machine with cifs works. Nothing special, default cifs network share mounting was used.

@crmabs Not in my case. I've mount shared NTFS drives with cifs in WSL2 (cuz 9p is so slow), but trying to access case sensitive folder gives the following error: ls: cannot access '/mnt/e/case-sensitive-test/': Input/output error

[b-hayes]

yeah, I was surprised by this problem as well. I just wanted to copy some old piece of code from my archived projects on my old machine and I cant.

Guess I have to get off my ass and look for a USB stick or email it to myself from my other machine 🤣.

I'm not sure why this is a problem tho, both machines can use case sensitive files.

[crmabs]

But mounting it from a remote machine with cifs works. Nothing special, default cifs network share mounting was used.

@crmabs Not in my case. I've mount shared NTFS drives with cifs in WSL2 (cuz 9p is so slow), but trying to access case sensitive folder gives the following error: ls: cannot access '/mnt/e/case-sensitive-test/': Input/output error

Hmff, probably my 'nothing special' wasn't true. Or it's getting updated.. #prayingforfix #fix4xmas

[ioweb-gr]

This has effectively crippled my network shares.

This is a real killer. I doubt it will ever get fixed

I've had to implement SSHFS to work around the limitation on windows

[razrjk]

I'm experiencing this problem too (not with WSL though) in a Docker with Ubuntu container trying to configure symbolic links (which I was able to do) and case insensitivity for a cifs mount of a Host ntfs filesystem. The error is:
ls test/CASE-sensitivity-test/CASE-sensitive-DIR
ls: cannot access 'test/CASE-sensitivity-test/CASE-sensitive-DIR': Input/output error

Host is Windows 11 enterprise.
Container Ubuntu 22.04 LTS

Mount command:
mount -v -t cifs //MYHOST/D/test test -o
"username=xx,domain=localhost,uid=1001,gid=1001,vers=3.0,soft,rsize=8192,wsize=8192,mfsymlinks,sec=ntlmv2"

Appears to be an SmbServer problem interoperating with ntfs setCaseSensitiveInfo enable.

[suntong]

This has effectively crippled my network shares.

This is a real killer. I doubt it will ever get fixed

Yep, I got hit unexpectedly as well --

The case-insensitive directory gave me trouble when doing git clone, but after turning the case-sensitive on for my shared directory, I cannot even visit it within the same machine, let alone the remote share.

This is really troublesome.

[ioweb-gr]

Case sensitivity and max_path limitations shouldn't be even a point of discussion nowadays. They should be allowed by default and no limit imposed and if needed for compatibility reasons make them optional choices with a toggle.

If you check the number of upvotes on such a technical matter on the feedback hub you'll see the demand is high.

[coldacid]

What a "wonderful" bug to run into.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!

[suntong]

This issue has been automatically closed since it has not had any activity for the past year.

I upvoated a message just days ago.

Such two-bit scheme policy make it a perfect one for people to spam the comments with "me too" than just upvoate!