dnlmlr/cargo-clean-all

cargo-clean-all's Issues

Infinite symlink loop during size calculations

Hey, thanks for the tool!

I tried to run cargo-clean -i in the dir containing all the projects I contribute into (~200, mostly not rust), and the CLI is hanging forever, trying to scan all the files looking for target/ directories. Peeking at the code, there seems to be no early return when the dir is not a rust project, which mean it will then recursively scan all dirs (including artefacts! the dreaded node_modules/ and so on).

This is a supposition, as even with --verbose mode I couldn't see where/what it was looking at.

couple of options:

• Manual maximum --depth option. Easy but no super user-friendly
• Limit to git-tracked files by default, which should avoid scanning all build artefacts.
• Trying to detect non-rust projects. There's a good list here: https://github.com/stevegrunwell/asimov/blob/a319695e4e351c6fe9623d079bb4d228950fdcb2/asimov#L36 already that could be used to early-return
• Maybe there's an external lib that does the detection already

Multiselect in interactive mode is buggy for long lines (dialoguer problem)

Ref: console-rs/dialoguer#227

Don't panic if `remove_dir_all` fails (and remove other panics that can actually be reached)

This is in reference to #4 but also has to be ported to the dev branch

Too slow on Windows

Problem

cargo clean-all is too slow on Windows.

Up to 37 times slower than cargo clean-recursive if there are many files on target.

How to reproduce the problem

Run on PowerShell.

Create test directory.

> cargo new clean_sample_project
> cd .\clean_sample_project\

Edit Cargo.toml

[dependencies]
actix-web = "=4.0.1"

Run builds and generate files in target.

> cargo doc; cargo build; cargo build --release

Measure cargo clean-all -y execution time.

> Measure-Command { cargo clean-all -y }

cargo clean-all takes 463.06 sec and cargo clean-recursive takes 12.24 sec in my environments.

Environments

CPU: AMD Ryzen 9 3900X 12-Core Processor 3.79 GHz
OS : Windows 10 Pro 21H2 19044.1645
SSD: WESTERN DIGITAL WD Black SN750 NVMe WDS200T3XHC

rustc 1.58.1 (db9d1b20b 2022-01-20) x86_64-pc-windows-msvc
cargo-clean-all v0.4.0

Selected to clean a project inside cargo's checkout directory

Running cargo clean-all on my system I see this suggestion:

  wasm_kernel : /home/brian/.cargo/git/checkouts/wasmi-7c64eb2d2cc9c309/7b1f235/benches/wasm/wasm_kernel
      2022-08-29 12:08, 798.53 KB

It's the only one inside my .cargo directory. Presumably wasmi accidentally packaged a target directory, but I haven't looked closely. It seems like deleting stuff from inside cargo's checkout directory could be disruptive to cargo.

Hidden Cursor during yes/no prompt

For me, I think it would be beneficial if the cursor was visible when the user is prompted:

Clean the project directories shown above? [y/n]

It could be hidden again once an input is captured. I think this is a simple fix that I would create a PR for.

Also, if one executes a CTRL+C at this stage, the application will crash;

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Interrupted, error: "read interrupted" }', /home/jack/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-clean-all-0.5.0/src/main.rs:219:14

Scanning for projects on Windows takes forever

I used this tool on Linux and liked it, so was also trying to use it on my Windows machine. However, when I ran it on a (relatively large) git projects directory, it takes a very long time - not sure exactly how long yet, but at least 5 minutes and still going.

Running in verbose mode doesn't give me any hint as to what's taking so long - I definitely have some projects with large subdirectory trees, but I'd still not expect it to take near this long. I can do some local debugging if you want any more information.

Add `--skip` argument to prevent scanning specified directories

Implement an argument to completely skip over specified directories while scanning. This can be used to speed up the scans by ignoring large directory structures that are known to not contain relevant projects.

The previously available --ignore should be kept around to provide the not freed, but freeable space metrics.

Ref: #9

Option to keep executables / libraries

In some cases it might be beneficial to keep the actual executables / targets of a rust project, but still delete all the other artifacts. This will free up most of the used space, but retain the possibility to use the executable in the future without needing to recompile the whole project.

To implement this feature, a few changes would have to be made:

• Find out what files should be considered as the mentioned executables / libraries somehow
• Adjust the scanning to ignore projects which only have these files left
• Change the recursive deletion to keep the files

Hi! I wanna add String read when Input specific_size, I will submit a PR

I am user of this crate, I confuse at unit of size input when I using.

so I wanna fix it complete at this point.

could I submit a PR for this?

@dnlmlr