cargo clean ate my entire project

[djugei]

Problem
cargo clean ate my entire project

i entered cargo clean and expected the target directory to be gone. my project was gone instead.

Steps
set cargo target dir to nothing, for example by executing

export CARGO_TARGET_DIR=

because you don't know bash and thought thats how you clear environment variables.

then run cargo clean on something you don't care about, like for example the thing you have been working on for the last while and only have a 10 days old backup of.

Possible Solution(s)
cargo clean should not behave like rm -rf, but at most like rm -r, not deleting .git and stuff without warning even on incorrect configuration.

another option would be to only delete directories/directory trees that have the CACHEDIR.TAG that cargo already helpfully creates to mark the directory as being a cache directory that can be deleted without ill consequences.

Notes
:(

[jyn514]

I have the same bug report (although fortunately I didn't run cargo clean). CARGO_TARGET_DIR= should unset the variable, not treat it the same as ..

[est31]

Re the CACHEDIR.TAG point, will any non-clean cargo command just put it into the root of your project if you have set export CARGO_TARGET_DIR=?` Also, older cargos dont create it, you might still want to be able to delete stuff.

A better check would IMO be whether any of the the files to be deleted are tracked by git, and if so, bail out with an error. Cargo publish IIRC already has a similar mode.

[jyn514]

@est31 sure, a sanity check for CARGO_TARGET_DIR=. would be nice. But that shouldn't be the behavior of DIR= in the first place - that should act exactly the same as not setting the variable. I think the issue is that the default is target/, not the empty string, and cargo is missing logic to explicitly treat the empty string as target/.

[est31]

@jyn514 that has some dangerous implications when multiple cargo versions use the same project. I think if that's done, one should at least emit errors for a while, say a few months to a year, and then switch the behaviour.

[jyn514]

I don't understand what the dangerous implications would be. Target directories aren't ever shared across toolchain versions AFAIK.

[est31]

@jyn514 well someone just complained that having CARGO_TARGET_DIR= deleted their entire project. If CARGO_TARGET_DIR= is interpreted as target/, folks might adopt it in makefiles/python scripts etc that call cargo clean and it might work well on modern cargos but not on older ones where it deletes. So someone checking out a project might be disappointed. It's more likely they use a copy of the project in such an instance, but not guaranteed (shared network drive, usb hdd, etc).

[djugei]

the cachedir.tag point is kinda moot, thinking about it. a previous build would create it (unless it checks for the directory being empty)