failed to link 'share/terminfo/h/hp70092A' in wsl2 ubuntu when UTF-8 character included in directory

[IncubatorShokuhou]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

on WSL2 ubuntu 22.04, in a directory include Chinese character:

0. cd /mnt/d/测试
1. pixi init test
2. cd test
3. pixi add numpy
   and then error:

  × failed to link 'share/terminfo/n/ncr260vt300wpp'
  ├─▶ failed to copy file to destination
  ╰─▶ Symbolic link loop (os error 40)

Issue description

fail to run pixi on wsl ubuntu when directory includes utf-8 characters

Expected behavior

no error happened

[IncubatorShokuhou]

BTW, I've encountered utf-8 issues a few times on this project, particularly with directory paths. Would it be possible to include related tests in our automated testing process?

[baszalmstra]

Does this also happen with non-utf8 paths? Are you perhaps storing your environment on a Windows drive? Windows is case insensitive but the package you are trying to install needs a case sensitive file system. Imagine you have the following case:

fileA
filea # symbolic link to `fileA`

On a case insensitive filesystem this will be a single file and the symbolic link will point to itself creating the infinite recursion.

BTW, I've encountered utf-8 issues a few times on this project, particularly with directory paths. Would it be possible to include related tests in our automated testing process?

Yes! Contributions are welcome! :)

[IncubatorShokuhou]

Does this also happen with non-utf8 paths?

No.

Are you perhaps storing your environment on a Windows drive?

I am using WSL, and it seems that this issue has nothing to do with uppercase and lowercase letters.

[IncubatorShokuhou]

Yes! Contributions are welcome! :)

I am more than willing to contribute, but I am concerned that adding content related to UTF-8 characters to the CI process may cause many CI to fail in the short term, leading to chaos in the project. I believe it would be better for the maintainers to make the changes yourself, as you have a better grasp of the entire project.

[wolfv]

@IncubatorShokuhou this issue might indeed be best fixed in rattler - if you can add a little test there that would be very helpful (https://github.com/mamba-org/rattler/).

Just to be sure, does this issue also occur on Windows itself? We already fixed a couple of Unicode related issues ... so I would hope that not that much is failing.

[IncubatorShokuhou]

@IncubatorShokuhou this issue might indeed be best fixed in rattler - if you can add a little test there that would be very helpful (https://github.com/mamba-org/rattler/).

Just to be sure, does this issue also occur on Windows itself? We already fixed a couple of Unicode related issues ... so I would hope that not that much is failing.

I tested the issue where the path contains UTF-8 characters, and the results are as follows:

1. In PowerShell: No issues occurred.
2. In the /mnt/d directory under WSL: The problem appeared.
3. In the ~/ directory under WSL: No issues occurred.
4. Repeating steps 1-3 on another computer yielded identical results.
5. In native Ubuntu: No issues occurred.
6. On an Armbian (running Debian on an arm64 platform): No issues occurred.

[baszalmstra]

In the /mnt/d directory under WSL: The problem appeared.

Yeah that confirms my suspicion. /mnt/d is a case insensitive filesystem under WSL. If you are installing a linux package on that drive and the package contains files with different capitalization issues may occur.

[RaphaelMelanconAtBentley]

I'm getting a similar issue which I'm not sure is related:

  ├─▶ failed to link 'share/terminfo/2/2621a'
  ├─▶ unexpected io operation while removing clobbered file
  ╰─▶ No such file or directory (os error 2)

Pixi v0.22.0 in a docker container running ubuntu 22.04