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

[IncubatorShokuhou]

Checks

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

• [X] 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

[benmoss]

I am running into this too, I managed to create a pretty minimal repro on my machine https://github.com/benmoss/pixi-symbolic-link-bug

➜  pixi-repro git:(main) pixi info
      Pixi version: 0.23.0
          Platform: osx-arm64
  Virtual packages: __unix=0=0
                  : __osx=14.5=0
                  : __archspec=1=m2
         Cache dir: /Users/bmoss40/Library/Caches/rattler/cache
      Auth storage: /Users/bmoss40/.rattler/credentials.json

Project
------------
              Name: pixi-repro
           Version: 0.1.0
     Manifest file: /private/tmp/pixi-repro/pixi.toml
  Config locations:
      Last updated: 03-06-2024 10:48:28

Environments
------------
       Environment: default
          Features: default
          Channels: conda-forge
  Dependency count: 1
      Dependencies: pytest
 PyPI Dependencies: python-git
  Target platforms: osx-arm64, linux-64, linux-aarch64

[ruben-arts]

Thanks @benmoss !! I unfortunately cannot recreate the bug on my linux machine. @nichmor could you give it a try on your mac?

[pavelzw]

The conda world if ncurses-linux-64 didn't have share/terminfo/n/ncr260vt300wpp and share/terminfo/N/NCR260VT300WPP in its package

https://github.com/conda-forge/ncurses-feedstock/issues/73

[PanTheDev]

Might it have something to with the locals not set properly? Adding locales to my container fixed it for me.

[garymm]

I'm seeing this running pixi install using the official ghcr.io/prefix-dev/pixi container image running in a devcontainer on MacOS. It seems by default MacOS filesystems are case-insensitive, and this carries through to the devcontainer :-(

[pavelzw]

@garymm https://github.com/prefix-dev/pixi/discussions/600#discussioncomment-8906188

[baszalmstra]

I'm closing this issue. It has to do with mounted a case-insensitive file system in a case-sensitive environment.

This is the same issue as: https://github.com/prefix-dev/pixi/issues/234

The solution is to make sure that your pixi environment is not on case-insensitive filesystem.

Please open a new issue if you feel I closed this issue too soon.