Case insensitive volume mounts broken

[theryansmith]

• I have tried with the latest version of my channel (Stable or Edge): Stable
• I have uploaded Diagnostics
• Diagnostics ID: F317A88E-BFE4-4D75-AC5E-8FF4274E9B94/20200313151904

Expected behavior

docker run --rm --volume c:\:/mnt/c ubuntu:18.04 ls -al /mnt/c/Windows
SUCCESS
docker run --rm --volume c:\:/mnt/c ubuntu:18.04 ls -al /mnt/c/WINDOWS
SUCCESS
Both should work, and it DOES with docker desktop 2.1.0.5, even though the c:\Windows directory exists only once, and with case Windows

Actual behavior

docker run --rm --volume c:\:/mnt/c ubuntu:18.04 ls -al /mnt/c/Windows
SUCCESS
docker run --rm --volume c:\:/mnt/c ubuntu:18.04 ls -al /mnt/c/WINDOWS
FAILURE (ls: cannot access '/mnt/c/WINDOWS': No such file or directory)
Both should work, but in docker desktop 2.2.0.4 (and 2.2.0.0, and 2.2.0.3), the directory is not found.

Information

• Is it reproducible?
  Yes

• Is the problem new?
  Since docker 2.2.0.0 update

• Did the problem appear with an update?
  Since docker 2.2.0.0 update

• A reproducible case if this is a bug, Dockerfiles with reproduction inside is best.
  docker run --rm --volume c:\:/mnt/c ubuntu:18.04 ls -al /mnt/c/WINDOWS

• Windows Version: Windows 10, Version 1809

• Docker Desktop Version: 2.2.0.4 (and 2.2.0.0, and 2.2.0.3)

• Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM: No

Steps to reproduce the behavior

1. docker run --rm --volume c:\:/mnt/c ubuntu:18.04 ls -al /mnt/c/Windows
   success

2. docker run --rm --volume c:\:/mnt/c ubuntu:18.04 ls -al /mnt/c/WINDOWS
   FAILURE (ls: cannot access '/mnt/c/WINDOWS': No such file or directory)

[stephen-turner]

Thanks for the report, @theryansmith. I can confirm I've reproduced it in 2.2.2.0. This is strange because I thought we'd tested all these cases. We'll look at it.

[stephen-turner]

I was confused about this. Actually this is by design. It's just that the docs haven't caught up yet. Here's what the next version of the docs will say:

Windows presents a case-insensitive view of the filesystem to applications while Linux is case-sensitive. On Linux it is possible to create 2 separate files: test and Test, while on Windows these filenames would actually refer to the same underlying file. This can lead to problems where an app works correctly on a developer Windows machine (where the file contents are shared) but fails when run in Linux in production (where the file contents are distinct). To avoid this Docker Desktop insists that all shared files are accessed as their original case. Therefore if a file is created called test, it must be opened as test. Attempts to open Test will fail with "No such file or directory". Similarly once a file called test is created, attempts to create a second file called Test will fail.

[gitfool]

@stephen-turner this looks similar to issue #5822. What do you think?

[stephen-turner]

@gitfool No, I don't think it's the same, but I have replied to your other ticket.

[stephen-turner]

Closing this ticket now, as the behaviour is by design.

[theryansmith]

@stephen-turner Is there any reference to why this feature was intentionally implemented other than that comment? I'm wondering if there was a discussion about it and if the decision can be reversed. This is breaking backwards compatibility.

My logic is: while this "feature" seems to have been intentionally implemented to fix the case where a windows dev host environment doesn't match a linux prod host environment, it breaks a specific case where you have a homogeneous windows dev+prod environment and have an application running in those containers that does not know the case of the files.

This functionality breaks applications that depended on the functionality that was available up to 2.1.0.5 and is a standard expectation in some windows applications. Can it at least be hooked up to be optionally enabled/disabled?

[theryansmith]

I think there is a decent argument to be made that the filesystem that IS case insensitive, should act as if they ARE case insensitive. In the 2.2.0.4 release notes there is even a reference to the fact that with windows mounts:

• creating files is acting case INsensitively (fails with EEXIST when try to create file with same name but different case)
• while accessing files is treated case sensitively (fails when try to access file with wrong case)

This is lacking consistency. In my opinion, acting consistently, and matching reality, are probably better here. At least optionally.

"Attempts to create files in a shared volume with an identical filename but a different case (uppercase/lowercase) on Windows filesystem will now fail with the error EEXIST."

[theryansmith]

Also, is there a Breaking changes and incompatibilities rule/goal for docker for win? If so, this change should be evaluated for rather or not it broke that rule.

[stephen-turner]

We should have release noted it; that was an oversight.

[theryansmith]

@stephen-turner thanks for your time. Is there any chance this decision could be reconsidered, or can I consider it as officially never again supported?

[stephen-turner]

Sorry, we are not planning to change it again. I think the case it's solving is more common than your case. We considered adding an option, but we prefer to keep the number of options small because parts of the code behind options tend to get undertested and break.

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked