Open testn opened 8 years ago
I'm not sure. Another mvn clean install will probably work as a retry.
It didn't because the cache file is installed into local maven repo
Maybe we should catch the exception and delete the file?
When you download, you should download to the temp folder before moving to the correct location.
i'm seeing this too:
file .m2/repository/com/github/eirslett/node/6.2.2/node-6.2.2-linux-x64.tar.gz
gives:
.m2/repository/com/github/eirslett/node/6.2.2/node-6.2.2-linux-x64.tar.gz: gzip compressed data, was "node-v6.2.2-linux-x64.tar", last modified: Fri Jun 17 14:32:16 2016, max compression, from Unix
du .m2/repository/com/github/eirslett/node/6.2.2/node-6.2.2-linux-x64.tar.gz
gives:
2372 .m2/repository/com/github/eirslett/node/6.2.2/node-6.2.2-linux-x64.tar.gz
tar xvf .m2/repository/com/github/eirslett/node/6.2.2/node-6.2.2-linux-x64.tar.gz .
gives:
gzip: stdin: unexpected end of file tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now
the only thing i can deduce on my end is that whatever java HTTP download client you are using will silently accept a broken transmission, or that the nodejs.org/dist server silently gave a partial file.
in any case, application logic to not get stuck in a bad state would be the fix :). our builds will keep trying to use that cached (and corrupted) file.
When running it on an unstable network, the file could be downloaded partially. This makes the subsequent operation to fail with " Could not extract the npm archive: Could not extract archive: ....". Is it possible to detect such corruption and re-download it?