dpc

It seems like the problem is not there in `v0.12.1`, so I rebased your commit on top of `v0.12.1`: ``` 9ca63fb40f4ff761a6cbb7d5c07f5fe4c98782b9 (HEAD -> symlink-artifacts, origin/symlink-artifacts) Symlink cargo build artifacts instead...

I tried again (to double check) just `v0.12.1` and it doesn't have the problem.

I'm using fenix toolchain. I reported https://github.com/ipetkov/crane/issues/323 , maybe it will shed some light.

I tried the current master with #334 and just so you're aware: in a larger project, just using zstd is still waaay better than not using, even with current optimizations....

We only need to call it on the resulting binaries no? At least with `use-zstd` the `./target` itself does not hold on to any outside references.

AFAICT all the symlinking stuff is not worth pursuing, and [taring the target dir (`use-zstd`) is best](https://github.com/ipetkov/crane/issues/76), including being faster, especially on non-trivial projects. I haven't redone the comparison after...

> My users are comparing Crane usage to raw Cargo, so the expectation on ‘I have made a small change’ is a relatively cheap build. Your users should keep using...

> For example, a typical Azure host will have 100-200MB/sec of disk write throughout, meaning that a 12GB extraction will take perhaps 1 minute - not insignificant, especially problematic if...

@j-baker I commented on your PR. It's probably an improvement, even if not in my favorite approach. :D BTW. It occurred to me that one reason why `zstd` compresses so...

In > the fact that they are warm in the memory is a plus. If you want a fast CI, you want your `./target` to fit in RAM one way...