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

Add Path to "failed to wrap \ld.lld\: failed to create unwraped directory" #4113

Open
C0D3-M4513R opened this issue Dec 14, 2024 · 1 comment

Comments

@C0D3-M4513R
Copy link

C0D3-M4513R commented Dec 14, 2024

Problem you are trying to solve

I want to check, why the error message below happens.
For that I'd like to investigate what's at the path, so I can potentially remove the offending file.

Error Message:

info: installing component 'rustc'
 70.2 MiB /  70.2 MiB (100 %)  13.4 MiB/s in  5s ETA:  0s
warning: failed to wrap `ld.lld`: failed to create unwrapped directory

Caused by:
    File exists (os error 17)

Stack backtrace:
   0: <rustup::dist::component::package::DirectoryPackage as rustup::dist::component::package::Package>::install
   1: <rustup::dist::component::package::TarGzPackage as rustup::dist::component::package::Package>::install
   2: rustup::dist::manifestation::Manifestation::update
   3: rustup::dist::dist::try_update_from_dist_
   4: rustup::install::InstallMethod::install
   5: rustup::toolchain::distributable::DistributableToolchain::update_extra
   6: rustup::cli::rustup_mode::update
   7: rustup::cli::rustup_mode::main
   8: rustup_init::main
   9: std::sys::backtrace::__rust_begin_short_backtrace
  10: main
  11: __libc_start_call_main
  12: __libc_start_main_alias_2
  13: _start
info: installing component 'rustfmt'

Solution you'd like

The offending path, that already exists should be displayed for the user to see, so that capable users can do something about the error.

Notes

This is happening on a NixOs install. It is quite possible, that this error is caused by some leftover symlink by home-manager.

@djc
Copy link
Contributor

djc commented Dec 16, 2024

Looking at <DirectoryPackage as Package>::install(), it's not completely obvious where this is coming from: we call utils::read_file() but it should yield an error that is contextualized with the file name (both on 1.27 and on master). The other filesystem operations are executed as part of a transaction which I think would have resulted in extra stack frames on this backtrace?

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

2 participants