Pin cache entries still in use

[epage]

Problem

Regardless of what automatic cleanup schedules we or the user chooses, we can end up removing files people need and they might not find out until they run in offline mode.

Proposed Solution

With #13136, we should know where all lockfiles are. We at least could pin all locally non-recreatable cache entries (e.g. index entries, .crate files) so that they don't get cleaned up, regardless of their age. Whether we should also pin recreatable cache entries is less clear though . It could help when a projects blow past low limits (see #12634 (comment)).

The main risk is the performance hit of reading all lockfiles and matching those to cache entries.

Notes

Blocked on #13136

[ehuss]

The team talked about this today and generally in agreement that it would be nice if we can do this. The main issues are:

• Blocked on tracking the locations of all Cargo.lock files (or whatever similar tracking mechanism) in Garbage collect whole target/ #13136
• Overall concerns about complexity and performance. Would need some investigation and experimentation.
  • Parsing all Cargo.lock files could be quite slow. This could be addressed with things like hashing the Cargo.lock file and recording the hash entries in the database, or some other database tracking mechanism.
  • Cargo.lock files could also be on removable drives, or network drives. Could cause hangs or other problems trying to open all of them.
  • Is this a use case that is important enough to justify the added complexity to cargo? Tough to determine since we are biased by having fast and readily available internet.