Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
[Windows] tar: Refusing to overwrite archive
See original GitHub issue
We’re hitting an issue when untar’ing a cached LLVM build on Windows:
llvm/lld/test/ELF/Inputs/aarch64-copy2.s: Refusing to overwrite archive
tar.exe: Error exit delayed from previous errors.
I’m reporting two bugs:
-
The above error. I don’t know what’s special about this file. This part of the workflow works when we don’t hit in the cache. (This is a new workflow which I’m still debugging.)
-
As a result of this warning, the
cache-hitoutput variable isn’t being set but the cache has been at least partially restored, resulting in an error in the rebuild step. The intuitive behavior in case of this error is to fail in the cache step. Alternatively, don’t fail, don’t set cache-hit, but clean up the (partially) restored files. This second option would be tricky since in this case it’s overwriting the source files and adding the build outputs.
Here’s the relevant excerpt of the workflow:
# Try to fetch LLVM from the cache.
- name: Cache LLVM
id: cache-llvm
uses: actions/cache@v2
with:
path: llvm
key: ${{ runner.os }}-llvm-rel-${{ steps.get-llvm-hash.outputs.hash }}
# Build LLVM if we didn't hit in the cache. Even though we build it in
# the previous job, there is a low chance that it'll have been evicted by
# the time we get here.
- name: Rebuild and Install LLVM
if: steps.cache-llvm.outputs.cache-hit != 'true'
shell: pwsh
run: |
mkdir llvm/build
...
Issue Analytics
- State:
- Created 3 years ago
- Comments:5
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I confirm that I’m running into a similar issue today: https://github.com/godotengine/godot/runs/4778125249?check_suite_focus=true
There’s an unrecoverable error but the partially unarchived cache is still used, and the build fails due to a truncated file, which in turns makes all PR builds fail similarly.
(This on the macOS running, I guess the issue is not Windows specific.)
I would expect that failing to restore the cache leads to a clean build (and upload of a fixed cache).
Edit: To clarify, my cache restore error is not the same as @teqdruid’s, but the outcome is the same: the cache is partially restored but the step still passes, and this partial but damaged cache is used and breaks the build step.
I am running into this same issue as well. cache is corrupted and truncates the packages causing build errors:
This is on a linux runner.