cargo clean with target as a symlink fails

[mathstuf]

Problem

When target is a symlink, cargo clean removes it and then tries to remove files from underneath it:

% cargo clean
    Removing /home/boeckb/code/depot/group-kitware/proj-kwrobot/ghostflow-director/src/target
error: failed to remove build artifact

Caused by:
  failed to remove file `/home/boeckb/code/depot/group-kitware/proj-kwrobot/ghostflow-director/src/target/.rustc_info.json`

Caused by:
  No such file or directory (os error 2)

Prior to 1.62, the symlink was removed and then nothing else was attempted. If it is a symlink, it should be removed last so that any other file deletions can still work.

Steps

% mkdir cargo-clean
% cd cargo-clean
% cargo init
     Created binary (application) package
% mkdir build
% ln -s build target
% ls -l
total 4
drwxr-x---. 2 user user   6 Aug  9 20:20 build
-rw-r-----. 1 user user 180 Aug  9 20:20 Cargo.toml
drwxr-x---. 2 user user  21 Aug  9 20:20 src
lrwxrwxrwx. 1 user user   5 Aug  9 20:20 target -> build
% cargo build
   Compiling cargo-clean v0.1.0 (/home/boeckb/misc/code/sb/cargo-clean)
    Finished dev [unoptimized + debuginfo] target(s) in 0.25s
% cargo clean -v
    Removing /home/boeckb/misc/code/sb/cargo-clean/target
error: failed to remove build artifact

Caused by:
  failed to remove file `/home/boeckb/misc/code/sb/cargo-clean/target/.rustc_info.json`

Caused by:
  No such file or directory (os error 2)

Possible Solution(s)

No response

Notes

See also #7510 and #7527.

Version

% cargo version --verbose
cargo 1.71.0
release: 1.71.0
host: x86_64-unknown-linux-gnu
libgit2: 1.6.4 (sys:0.17.1 vendored)
libcurl: 7.85.0 (sys:0.4.61+curl-8.0.1 system ssl:OpenSSL/3.0.9)
os: Fedora 37.0.0 [64-bit]

Also tested with rustup from 1.53 to stable: 1.61 is fine and 1.62 has this behavior.

[ehuss]

I suspect this was a consequence of #10236 switching to use walkdir with contents_first.

I am currently in the process of changing how that function works, and it should fix this issue. I'll see if I can get that separated out as a separate PR in the next few weeks.

[mathstuf]

FWIW, it's been broken for over a year (10 release cycles). I don't think it's that important to require a separate PR if it's a lot of work. I'm actually finding that cargo clean has never really liked my "target is a symlink" preference anyways (at least since 1.53) because it just removes the symlink and doesn't actually clean things, so there's no need to rush a specific fix (on my behalf at least).

[weihanglo]

Confirmed this is resolve in 1.74.0 with

cargo/src/cargo/ops/cargo_clean.rs

Line 364 in 3b43aa8

for entry in walkdir::WalkDir::new(path).contents_first(true) {

Closing and thanks for the report.

[mathstuf]

FWIW, 1.78 now just removes the symlink; data still persists after cargo clean. At least it doesn't fail now though :) .

[weihanglo]

data still persists after cargo clean

See #13670 for the behavior.