rustup update panic while cleaning cache
#2895
Labels
Comments
|
Just found that I can't reproduce the bug following the steps outlined here. Hm... |
|
We typically see permission errors in IO only on Windows - I have two guesses as to what this could be, neither are easy to reproduce reliably:
Do either of those ring bells? |
|
@kinnison No, none of those ring bells. |
|
What's the ownership on the two last directories in the path that fails to
delete?
…On Mon, 15 Nov 2021, 09:08 Andrew Sonin, ***@***.***> wrote:
@kinnison <https://github.com/kinnison> No, none of those ring bells.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2895 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZ7XVXWL4WJJUUM3YQLVTUMC5Y7ANCNFSM5HU3FWVQ>
.
|
|
Since then I have completely reinstalled However, the command total 0
0 drwxr-xr-x 2 andrewsonin staff 64B Nov 15 13:23 .
0 drwxr-xr-x 7 andrewsonin staff 224B Nov 9 13:13 ..I think the permissions could not be different from the current ones, since I worked with |
|
Thanks, though we would have needed the original numbers not the
re-installed ones to be able to exclude permissions as a cause.
On a non-windows OS, without permissions preventing deletion the only
remaining cause is a disconnected network drive, or a kernel security
module of some sort intercepting the operation.
…-Rob
On Mon, 15 Nov 2021 at 12:28, Andrew Sonin ***@***.***> wrote:
@rbtcollins <https://github.com/rbtcollins>
Since then I have completely reinstalled rustup, so there is no way for
me to recover this information.
However, the command ls -shal /Users/andrewsonin/.rustup/tmp now outputs
the following:
total 0
0 drwxr-xr-x 2 andrewsonin staff 64B Nov 15 13:23 .
0 drwxr-xr-x 7 andrewsonin staff 224B Nov 9 13:13 ..
I think the permissions could not be different from the current ones,
since I worked with rustup exclusively from the terminal without using
sudo.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2895 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZ7XWBQHEV6YQBPXY2G6LUMDVHDANCNFSM5HU3FWVQ>
.
|
|
I can repeatedly reproduce this right now on Mac OS 12.1 ARM64, will investigate.
The directory looks like this: No obvious permissions problems. I did not try to remove the directories manually yet. |
|
Hopefully the maintainers of |
|
I'm getting this error just after upgrading to rustc v1.58.1. I have write permissions for everything in
|
|
@cherryblossom000 I don't think its related; the remove_dir_all crate is not the same code as in the stdlib. |
|
@rbtcollins Merging XAMPPRocky/remove_dir_all#36 should fix this particular issue for Mac and other BSDs. |
|
I was having this issue too but it seems to be resolved when I stopped a |
|
I am running into this error today: It looks like maybe there's a toolchain in there from Meta |
|
got this issue today too |
|
Same for me on every ❯ RUST_BACKTRACE=full rustup update
info: syncing channel updates for 'stable-aarch64-apple-darwin'
info: syncing channel updates for 'nightly-aarch64-apple-darwin'
stable-aarch64-apple-darwin unchanged - rustc 1.65.0 (897e37553 2022-11-02)
nightly-aarch64-apple-darwin unchanged - rustc 1.67.0-nightly (32e613bba 2022-12-02)
info: cleaning up downloads & tmp directories
thread 'main' panicked at 'Unable to clean up /Users/bene/.local/share/rustup/tmp: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', src/utils/utils.rs:649:13
stack backtrace:
0: 0x1050aa668 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::ha610dc96df5533b5
1: 0x104d16f88 - core::fmt::write::h85a0222d7173f527
2: 0x105090f2c - std::io::Write::write_fmt::h1e81e1aae1f60926
3: 0x10509c69c - std::panicking::default_hook::{{closure}}::hafcdd34daa6aee47
4: 0x10509c39c - std::panicking::default_hook::hbdef0c99978ce86d
5: 0x10509cff8 - std::panicking::rust_panic_with_hook::he857adbde651a96b
6: 0x1050aac9c - std::panicking::begin_panic_handler::{{closure}}::h78d4b95de3b3c015
7: 0x1050aac14 - std::sys_common::backtrace::__rust_end_short_backtrace::h948efd9d51b5e877
8: 0x10509cab4 - _rust_begin_unwind
9: 0x10514472c - core::panicking::panic_fmt::h4c391ad4ab25a9e0
10: 0x104fb0dcc - rustup::utils::utils::delete_dir_contents::hd739cc10628ca647
11: 0x104f93180 - rustup::cli::rustup_mode::update::hab527212ec6417db
12: 0x104f7d2f0 - rustup::cli::rustup_mode::main::hc907663a8a5d3a35
13: 0x104ccc09c - rustup_init::main::h08e08969caf302d0
14: 0x104cca24c - std::sys_common::backtrace::__rust_begin_short_backtrace::he6ec1093de90141b
15: 0x104ccc76c - _main
########### info ##########
❯ lsd -al ~/.local/share/rustup/tmp/
drwxr-xr-x bene staff 192 B 2 minutes ago .
drwxr-xr-x bene staff 256 B 7 months ago ..
drwxr-xr-x bene staff 384 B 6 months ago m1hsw6y9gclxm5ki_dir
.rw-r--r-- bene staff 27 B 6 months ago 1t3wvduj6a3436gd_file
.rw-r--r-- bene staff 63 B 6 months ago lr6unlwf9mj_hf1b_file
.rw-r--r-- bene staff 1 B 6 months ago x3_k1cl1471rrwyv_file
❯ rustup show
Default host: aarch64-apple-darwin
rustup home: /Users/bene/.local/share/rustup
installed toolchains
--------------------
stable-aarch64-apple-darwin (default)
nightly-aarch64-apple-darwin
1.61.0-aarch64-apple-darwin
active toolchain
----------------
stable-aarch64-apple-darwin (default)
rustc 1.65.0 (897e37553 2022-11-02)
❯ rustup --version
rustup 1.25.1 (2022-07-12)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.65.0 (897e37553 2022-11-02)`
❯ sw_vers
ProductName: macOS
ProductVersion: 13.0.1
BuildVersion: 22A400
❯ uname -mprsv
Darwin 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:15:09 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T6000 arm64 arm
❯ rg rust ~/.config/fish/
/Users/bene/.config/fish/conf.d/xdg_env.fish
27:# Rust
29:set -gx RUSTUP_HOME $XDG_DATA_HOME/rustup
/Users/bene/.config/fish/completions/rustup.fish
1:# Generated by `rustup completions fish`
... |
|
got this issue today too |
|
Yes, even use |
|
Also getting this |
|
Also getting this on Ventura 13.1 (MacOs) |
Same here. |
|
You can close the rust environment in use and try closing vscode,delete files in tmp |
|
I'm getting this on Linux (Void). I recently got an issue fixed in ghcup which might correlate and was about filesystem features that are not available on all filesystems, posix flags for directories, etc: haskell/ghcup-hs#766 TL;DR; maybe the underlying filesystem is not returning what that crate expects and it bubbles up as a permission error, even though it's not a permision error per-ce. More info about |
It helped. Thanks |
This worked for me - I had VS Code running with rust-analyzer and ran |
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
Steps
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shrustup target add x86_64-unknown-linux-musl x86_64-pc-windows-gnurustup updatePossible Solution(s)
No response
Notes
No response
Rustup version
Installed toolchains
Operating system
macOS Monterey 12.0.1
The text was updated successfully, but these errors were encountered: