Skip to content

Mark ~/.cargo or some subdirectories with CACHEDIR.TAG #10457

@sourcefrog

Description

@sourcefrog

Problem

~/.cargo can be fairly large: 4.4G on the machine where I'm writing this, and it takes ~10s to walk.

Most of the content is copies of registries and source trees, which can be downloaded again, so in most situations it doesn't need to be backed up.

CACHEDIR.TAG https://bford.info/cachedir/ is a standard way of marking directories containing caches of information stored elsewhere, so that they can be excluded from backups, etc.

In the Rust ecosystem there is a cachedir crate to detect and insert these marks. At least one Rust backup tool, Conserve, excludes directories marked with CACHEDIR.TAG (using that library), as do other tools not written in Rust.

Proposed Solution

In short: Cargo should insert CACHEDIR.TAG files into either ~/.cargo itself, or some subdirectories.

This would be consistent with how target directories are now marked.

Which directories?

One subsidiary decision is whether to mark the whole of ~/.cargo or only some subdirectories. Most of it does seem to be a cache. However ~/.cargo/bin contains binaries from cargo install, and they may not be trivially recreatable, for example if they were built from cargo install --path, or if the user cares about restoring the exact version.

So, it would be more conservative to mark only git and registry.

When to mark them?

target seems to only get marked when it is first created.

This doesn't seem like a good fit for ~/.cargo, which already exists on every machine where people use the Rust toolchain, and should never normally be recreated.

So I'd argue it would be reasonable for Cargo to mark these directories every time it runs an operation that updates them, if the mark does not already exist.

Notes

See also:

Metadata

Metadata

Assignees

Labels

A-cachingArea: caching of dependencies, repositories, and build artifactsC-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions