Closed sourcedelica closed 4 months ago
I have been having a look to this issue.
Without fully being able to reproduce yet, I believe that this is an interaction between the info --paths
and the short_paths
feature. Can you verify that only happens for packages that have short_paths, but not for packages in the regular cache?
Apparently, it should only happen if the conan info --paths
is executed before an actual install of the packages, if a conan install
is done first, and then the conan info --paths
everything should work, could you please confirm too?
This problem seems very difficult to solve, due to the nature of the short_paths
architecture.
I forgot to mention, it works fine on Linux.
We have user_home_short = None
set in conan.conf
.
To replicate the problem I do:
conan install ..
in the build directory to populate the cache for that projectconan info . --paths
via the script above.So we are running conan install
(which installs the packages correctly), then conan info --paths
(which deletes files).
Here's something that looks interesting:
EPederson@NAD4ZWN853 MINGW64 /c/work/tw-base (feature/cpp17)
$ grep conan_link conan_files_before.out # Before running conan info --paths
$ grep conan_link conan_files_after.out # After
1688849860542557 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/build/e25da6736836401d14d18eb2361204b3783cc5f4/.conan_link
49821070877816853 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/.conan_link
1688849860542552 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/source/.conan_link
1688849860542565 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/libevent/2.1.12/_/_/build/8d05cc4afe9f09aef8bc2db914f3d5f066597fb7/.conan_link
1688849860542569 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/libevent/2.1.12/_/_/package/8d05cc4afe9f09aef8bc2db914f3d5f066597fb7/.conan_link
1688849860542560 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/libevent/2.1.12/_/_/source/.conan_link
2251799813964362 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/protobuf/3.6.1/bincrafters/stable/build/d057732059ea44a47760900cb5e4855d2bea8714/.conan_link
2533274790674466 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/protobuf/3.6.1/bincrafters/stable/package/d057732059ea44a47760900cb5e4855d2bea8714/.conan_link
2533274790674582 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/protobuf/3.6.1/bincrafters/stable/source/.conan_link
2251799813963951 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/protoc_installer/3.6.1/bincrafters/stable/build/9e449b1ac4341c7bdc87f8a7efe81200c68c405b/.conan_link
2251799813963955 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/protoc_installer/3.6.1/bincrafters/stable/package/9e449b1ac4341c7bdc87f8a7efe81200c68c405b/.conan_link
2814749767385136 1 -rw-r--r-- 1 EPederson 1049089 20 Feb 23 16:27 /c/Users/EPederson/.conan/data/protoc_installer/3.6.1/bincrafters/stable/source/.conan_link
$ conan get boost/1.76.0@ | grep short
short_paths = True
$ conan get libevent/2.1.12@ | grep short
short_paths = True
$ conan get protobuf/3.6.1@bincrafters/stable | grep short
$ conan get protoc_installer/3.6.1@bincrafters/stable | grep short
I forgot to mention, it works fine on Linux.
This is a strong indicator that the problem is indeed due to short_paths
. Even if the graph for protoxxx doesn't show short_paths
the folder are still showing a .conan_link
which is an artifact of the short_paths
feature.
Closing as outdated, short_paths
no longer exists since Conan 2
Environment Details (include every applicable attribute)
Steps to reproduce (Include if Applicable)
conan install ..
in the build directory to populate the cache for that projectconan info . --paths
Here is the script we are using to reproduce the problem, running in Git Bash. It does a
find
on the cache directory, then runsconan info --paths .
, then runsfind
again and diffs the outputs from the twofind
commands. The--paths
is important. The bug doesn't happen without--paths
.One thing: the bug does not trigger for some projects with fewer requirements.
Logs (Executed commands with output) (Include/Attach if Applicable)
Here is the conan info output from the test script:
Here is an excerpt of the diff showing missing files (it was 22k lines):