[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with identical file names with different capitalization #6369

Open
2 tasks done
swojdyga opened this issue Apr 18, 2020 · 10 comments
Open
2 tasks done

Problem with identical file names with different capitalization #6369

swojdyga opened this issue Apr 18, 2020 · 10 comments

Comments

@swojdyga
Copy link
swojdyga commented Apr 18, 2020
  • I have tried with the latest version of my channel (Stable or Edge)
  • I have uploaded Diagnostics
  • Diagnostics ID: CCAAD17B-B3FB-4C0B-97FF-07DBDA067006/20200503174456

Expected behavior

Just should work.

Actual behavior

At the moment moment when I try download package via composer (https://hub.docker.com/_/composer) I got error "The archive may contain identical file names with different capitalization (which fails on case insensitive filesystems): ZipArchive::extractTo(): File exists".

Information

Everything works great on Docker for Windows 2.1.x. Beginning from 2.2.x I have these issue.

Steps to reproduce the behavior

  1. Type docker run -v ${pwd}:/app -it composer require freshmail/rest-api.
@mat007
Copy link
Member
mat007 commented Apr 21, 2020

This looks similar to #5894 and I’m tempted to close this one as a duplicate.
I just checked with Edge 2.2.4.0 and it appears to be working properly.

What is your Docker Desktop version?

@swojdyga
Copy link
Author
swojdyga commented Apr 21, 2020

I tested it on version 2.2.0.5 - here the issue still exists.
On version 2.1.x everything works great.

Where can I get version 2.2.4.0? The latest version of https://docs.docker.com/docker-for-windows/edge-release-notes/ is 2.3.0.0 - here the issue still exists.

@swojdyga
Copy link
Author
swojdyga commented May 2, 2020

Can anyone help me? I still have this issue and working with it is uncomfortable.

@mat007
Copy link
Member
mat007 commented May 3, 2020

Ah sorry, that was a typo, 2.3.0.1 is the current latest Edge version released.
If you’re still facing the issue with that one, could you upload diagnostics (Troubleshoot windows from the systray menu)?
Thanks!

@swojdyga
Copy link
Author
swojdyga commented May 3, 2020

Here is my Diagnostics ID: CCAAD17B-B3FB-4C0B-97FF-07DBDA067006/20200503174456

@swojdyga
Copy link
Author

What about this issue?

@djs55
Copy link
djs55 commented May 13, 2020

@swojdyga thanks for your report. The root cause is that the underlying Windows filesystem (or at least the Win32 API to access it) is case insensitive. Since production is typically a Linux host which is case-sensitive, this can hide bugs: if one source code file includes another with the wrong case, it will work locally (potentially) but fail when pushed and run on Linux. In order to guarantee the property that if it works on my machine, it also works in production, Docker Desktop on Windows is now more strict about file case. Unfortunately this breaks some instances like this where the different case didn't really matter. I'm still not 100% how best to handle this problem.

In the meantime, I have a slightly unusual suggestion for you: I've been using a very good two-way file sync tool to synchronise source code between my host and Docker containers. It's called https://mutagen.io/ and we're planning to integrate it with Docker Desktop on Mac in the short term (see the roadmap). It supports Windows too. This would bypass the problem because composer would create the files on a native Linux filesystem which would then be synced back to the host, where you could edit them. Changes from the host are then picked up by a file watch and propagated back to the container. Let me know how it goes if you try this.

@thaJeztah
Copy link
Member

Related discussion on the "docker for mac" issue tracker; docker/for-mac#320 (comment)

@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

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

@thaJeztah
Copy link
Member

/lifecycle frozen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants