"Case insensitive filesystem can't manage this"

[JPGygax68]

I tried to install OpenCV3 as a dependency and found OpenCV/3.2.0@xmar/stable, which I added to my requires section.

There was no package available for my platform (Windows 10, Visual C++ 2015 32-bit), so I went with --build missing. The build seems to have run to completion, but right at the end, I got:

ERROR: Requested 'OpenCV/3.2.0@xmar/stable' but found case incompatible 'opencv'
Case insensitive filesystem can't manage this

(I tried other OpenCV packages, but they all had problems of one sort or another. I think this one is the most promising, if I can find a solution to the above problem.)

[memsharded]

One of them requires "OpenSSL" and the other "openssl". I add either one or another (also with "override") and conan just prefers to ignore me and tries to download both despite the "override" specifier

Conan is case-sensitive, OpenSSL and openssl are completely different packages. They cannot override each other, only the exact same package name can be overriden. The possibilities are either stop using legacy packages (those with uppercase letters) or other packages using the legacy ones (typically from other repos other than ConanCenter), ConanCenter started to use lowercase only more than 1 year ago, or to do not upgrade and do not use newer packages from ConanCenter.

Can we perhaps address this issue in the opposite direction?

Not worth the specifics of dealing with Windows APIs, too much effort and is typically a fragile approach. In any case, the redesign of the cache for Conan 2.0 is already happening: https://github.com/conan-io/conan/pull/8796. Conan 2.0 will use lowercase package names only (with an opt-out, https://github.com/conan-io/tribe/pull/17, and still different casing will mean completely different packages, but the new cache design will allow to store them for all OS without issues.)

[memsharded]

after lots of discussions, and submitting this to the Tribe 2.0 (https://github.com/conan-io/tribe/pull/17) the final conclusion was:

• To use always lowercase, for all packages (with a temporary migration opt-out in 2.0, to be removed in 2.X)
• The transition was a bit painful, but now it has been almost 2 years that ConanCenter is already using everything lowercase, so shouldnt be an issue anymore

This has been already implemented in develop2, will be released next 2.0.0-alpha2 (the alpha1 is already released), so I think this can be closed now.

[johan-boule]

We managed to make it work like this: fsutil file SetCaseSensitiveInfo $CONAN_USER_HOME/.conan/data Then, we patched the function _is_case_insensitive_os() so it returns False

[michkrom]

^^^ is interesting bandaid, thanks! Although hard to implement on shared build servers. However I would suggest the _is_case_insensitive_os() be patched to actually conduct a test rather than infer from the OS name. Linux may have case-insensitive file systems as well and as in the bandaid, Windows can be made case-sensitive.

For the record - I have to state that current approach to fix this by Conan2.0 is troubled.

The acceptance of Conan 2.0 will be hard if not impossible in real life complex environments (agree with @DoDoENT here). I work in a place running 100s of projects with 100s of sw engineers with uncounted internal and external dependencies and lots of cross dependent subcomponents. It's a gridlock. All on different schedule cycles. All targeting multiple OSes, many with cross-compiling builds. I do not see how we could move to Conan 2.0. And if we ever tried it would be multi-month effort with all projects halted. I do not see it happening :-(

Completely agree with @keysight-daryl here as well. A small mod to fix Windows cache (opt-in) proposed earlier would do a lot good in the mean time. We may end up forking conan for this to survive - but this would create a big maintenance problem.

Alternatively, some form of declarative "name equivalence" that each conanfiles could state? Say "OpenSSL=openssl" hence considering these "equivalent" and thus not distinguishing these two as separate components for storage and version resolution purpose. This would also help in other cases where the component's name was changed but component is still the same (although that may have cmake implications).

[michkrom]

Ah! The name equivalence could be achieved with provides attribute. However, that could only be stated in dependency (package). I'd like to to be able to state that also in root (consumer) to avoid needles local package copies.

[eclazi]

We managed to make it work like this: fsutil file SetCaseSensitiveInfo $CONAN_USER_HOME/.conan/data Then, we patched the function _is_case_insensitive_os() so it returns False

Unfortunately does not work on Windows 11, as fsutil now requires the directory to be empty when using SetCaseSensitiveInfo

[memsharded]

@eclazi in any case, ConanCenter has been mandating all lowercase package names since years, and Conan 2.0 will also force lowercase for all packages. Start to convert your package names to lowercase to be ready.

[johan-boule]

They are other reasons that make the .conan/data dir not sharable at all between different versions of a project/branch:

1) As documented, it's not thread safe, so CI are recommended to use a separate CONAN_USER_HOME (and shared download cache) for each build.

2) You want each version/branch of your software to lock the package revisions it needs, and these will differ between versions/branches of your software, and that data dir does not allow storing the same package in several revisions.

These points are enough to make the case-sensitivity problem just go away, as you just can't "share" the data dir anyway.

[memsharded]

Some hints following @johan-boule points:

You want each version/branch of your software to lock the package revisions it needs, and these will differ between versions/branches of your software, and that data dir does not allow storing the same package in several revisions.

This is fixed by 2.0, the cache there will be multi-revision

As documented, it's not thread safe, so CI are recommended to use a separate CONAN_USER_HOME (and shared download cache) for each build.

In 2.0, at the moment, it is still not thread-safe, but this is something that will be tried in the future

[eclazi]

I am fine to migrate all packages to lowercase, however the main problem for me is that when trying to build older versions it will need the mixed case packages (OpenSSL looking at you). I need to maintain the ability to build these older versions.

[memsharded]

Conan 2.0 will no longer be able to build legacy recipes that have not been modernized in 1.X to the new tools (https://docs.conan.io/en/latest/conan_v2.html). If the recipes need to be updated, fixing the name shouldn't be an issue anyway?

[eclazi]

Yeah, when Conan 2.0 is released and stable, I'm sure we will address that during if we decide to migrate. But for now we're using Conan 1.x

[memsharded]

Yeah, when Conan 2.0 is released and stable, I'm sure we will address that during if we decide to migrate. But for now we're using Conan 1.x

We expect 2.0, hopefully, before EOY. Also, all necessary recipe upgrades have been backported and can already be implemented in 1.X, and that is the recommended approach anyway in 1.X, because the legacy tools will not longer be maintained. Changing the package names to lowercase can also be done (and should be done) in 1.X, not in 2.0, because the idea is that updated recipes will be compatible 1.X<->2.0.