# Caching ${TRAVIS\_HOME}/.cargo does not work with bash branch of basher

**URL:** <https://travis-ci.community/t/caching-travis-home-cargo-does-not-work-with-bash-branch-of-basher/1961>\
**Category:** Windows\
**Tags:** caching, bug\
**Created:** [January 22, 2019, 10:05pm UTC](https://travis-ci.community/t/caching-travis-home-cargo-does-not-work-with-bash-branch-of-basher/1961 "2019-01-22T22:05:27Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![phil-opp](https://avatars.discourse-cdn.com/v4/letter/p/ad7895/32.png) [@phil-opp](https://travis-ci.community/u/phil-opp)\
**Post date:** [January 22, 2019, 10:05pm UTC](https://travis-ci.community/t/caching-travis-home-cargo-does-not-work-with-bash-branch-of-basher/1961/1 "2019-01-22T22:05:27Z")

</div>

The `${TRAVIS_HOME}/.cargo` directory is used by Rust’s cargo to store executables installed through `cargo install`. However, the cached directory does not contain the installed executables on the next run on Windows.

I verified that the correct cache file is restored:

- job 1: installs the executables, verifeis that they’re available in `${TRAVIS_HOME}/.cargo/bin`, and caches that directory in a file named `PR.535/cache-windows-1803-containers-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--cargo-nightly.tgz`
- job 2: restores `PR.535/cache-windows-1803-containers-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--cargo-nightly.tgz` (the exact same name), but the installed executables are no longer in `${TRAVIS_HOME}/.cargo/bin`.

This leads to really long build times since the executables are recompiled in each job.

---

<div class="post-metadata">

**Author:** ![phil-opp](https://avatars.discourse-cdn.com/v4/letter/p/ad7895/32.png) [@phil-opp](https://travis-ci.community/u/phil-opp)\
**Post date:** [January 22, 2019, 10:38pm UTC](https://travis-ci.community/t/caching-travis-home-cargo-does-not-work-with-bash-branch-of-basher/1961/2 "2019-01-22T22:38:09Z")

</div>

I did some investigation: it seems like the problem is in the `bash` branch of [`casher`](https://github.com/travis-ci/casher). When I add the `branch: bash` to my travis config as described [here](https://changelog.travis-ci.com/caching-is-now-enabled-in-windows-with-rewritten-caching-utility-76161), I see the same behavior on Linux and macOS.

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [January 23, 2019, 9:38am UTC](https://travis-ci.community/t/caching-travis-home-cargo-does-not-work-with-bash-branch-of-basher/1961/3 "2019-01-23T09:38:36Z")

</div>

Could you point to the build log URL to show the problem?

---

<div class="post-metadata">

**Author:** ![phil-opp](https://avatars.discourse-cdn.com/v4/letter/p/ad7895/32.png) [@phil-opp](https://travis-ci.community/u/phil-opp)\
**Post date:** [January 23, 2019, 10:06am UTC](https://travis-ci.community/t/caching-travis-home-cargo-does-not-work-with-bash-branch-of-basher/1961/4 "2019-01-23T10:06:32Z")

</div>

Sure:

- Job [483091891](https://travis-ci.org/phil-opp/blog_os/jobs/483091891): On the first `ls ${TRAVIS_HOME}/.cargo/bin` the executable `bootimage.exe` is not present. It is then installed and shows up on the second  
`ls ${TRAVIS_HOME}/.cargo/bin`. At the end of the job, the build cache is updated and the `bootimage.exe` is [listed as new file](https://travis-ci.org/phil-opp/blog_os/jobs/483091891#L745). (The output is mangled, I don’t know it that’s the problem).
- Job [483110208](https://travis-ci.org/phil-opp/blog_os/jobs/483110208): On the subsequent job the cache is restored (same cache file name), but the first `ls ${TRAVIS_HOME}/.cargo/bin` does not contain `bootimage.exe`.
  - The [Linux](https://travis-ci.org/phil-opp/blog_os/jobs/483110205) and [macOS](https://travis-ci.org/phil-opp/blog_os/jobs/483110206) jobs of the same build (default casher) have the `bootimage` executable present after restoring the cache.

When I change `casher` to the `bash` branch (`branch: bash`), the Linux (and macOS) builds show the same behavior as Windows:

- Job [483123213](https://travis-ci.org/phil-opp/blog_os/jobs/483123213): First job after switching to `branch: bash`.
- Job [483131073](https://travis-ci.org/phil-opp/blog_os/jobs/483131073): Subsequent job restoring the cache, but the `${TRAVIS_HOME}/.cargo/bin` directory does not contain the `bootimage` executable.

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [January 23, 2019, 10:56am UTC](https://travis-ci.community/t/caching-travis-home-cargo-does-not-work-with-bash-branch-of-basher/1961/5 "2019-01-23T10:56:17Z")

</div>

I see. `\t` in the path inside `${TRAVIS_HOME}` is interpreted as a tab, resulting in the wrong path when creating the cache archive.

---

<div class="post-metadata">

**Author:** ![phil-opp](https://avatars.discourse-cdn.com/v4/letter/p/ad7895/32.png) [@phil-opp](https://travis-ci.community/u/phil-opp)\
**Post date:** [January 24, 2019, 12:56pm UTC](https://travis-ci.community/t/caching-travis-home-cargo-does-not-work-with-bash-branch-of-basher/1961/6 "2019-01-24T12:56:16Z")

</div>

Ah, that explains the strange output. I see that there is an open PR for this at [https://github.com/travis-ci/casher/pull/38](https://github.com/travis-ci/casher/pull/38). Are there any ways to work around that issue until it is merged?

---

<div class="post-metadata">

**Author:** ![Lekensteyn](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/lekensteyn/32/880_2.png) [@Lekensteyn](https://travis-ci.community/u/Lekensteyn)\
**Post date:** [January 28, 2019, 11:23am UTC](https://travis-ci.community/t/caching-travis-home-cargo-does-not-work-with-bash-branch-of-basher/1961/7 "2019-01-28T11:23:33Z")

</div>

It does not try to create paths containing tabs, that is just a display issue (but highly confusing). The problem is lack of support for absolute paths (which is fixed by the PR linked above).

Some more details (and an ugly workaround) are documented at:

> [@Feedback from Windows integration for a CMake + Qt + C + Python + Perl project](https://travis-ci.community/t/feedback-from-windows-integration-for-a-cmake-qt-c-python-perl-project/1706):
>
> Hi! Thanks for making an early preview available of Windows on Travis. I’ve been trying to add Windows support to our existing .travis.yml configuration which already supports Linux and macOS. Below I’ll share some issues I encountered during integration along with workarounds and suggestions for improvement. A few characteristics of the project: Already supports Linux (Xenial) and macOS on Travis. Uses CMake as build system. MSVC is preferred (assumed?) on Windows. The build process require…

Basically it requires you to move the extracted directory (probably named “Users” for C:\Users.…) from the current directory to the right location and recompute the cache checksums to avoid reuploading the same cache at the end of the test run.

Another idea is to cache the `.cargo` directory in the current working directory and attempt to create a symlink from `$TRAVIS_HOME/.cargo` as relative paths should be handled just fine. Not sure how well that is supported on Windows though.

@BanzaiMan Please consider merging [Bash fixes for extracting absolute paths and corrected message prints by Lekensteyn · Pull Request #38 · travis-ci/casher · GitHub](https://github.com/travis-ci/casher/pull/38), it would allow some ugly hacks to be removed from the .travis.yml files.
