nvm install may failed with broken cache

[PeterDaveHello]

A broken local cache may fail the installation process as below, please note that the output was generated by a modified nvm by my patch, for help debug and improve the user experience.

$ nvm i 5                                              
Downloading and installing node v5.12.0...
Local cache found - $NVM_DIR/.cache/bin/node-v5.12.0-linux-x64/node-v5.12.0-linux-x64.tar.xz
Checking its checksum ...
Computing checksum with sha256sum
Checksums do not match: 'ee97c28bea7b39b812ff1f83f66298014e1f7ab29f491f38d541540cb997764b' found, '619fc1d14ee0c92894cf01bf1a47f5bae321ac04dfeb4cea6a2b6ce65832df79' expected.
Checksums match failed!
Fallback to download https://nodejs.org/dist/v5.12.0/node-v5.12.0-linux-x64.tar.xz
######################################################################## 100.0%
Computing checksum with sha256sum
Checksums do not match: '4aaad95d615190e4d68eba977ce586951f6e2d409de35e214bd5114d3ddfc6fc' found, '619fc1d14ee0c92894cf01bf1a47f5bae321ac04dfeb4cea6a2b6ce65832df79' expected.
xz: (stdin): Compressed data is corrupt
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Binary download failed, trying source.
Local cache found - $NVM_DIR/.cache/src/node-v5.12.0/node-v5.12.0.tar.xz
Checking its checksum ...
Computing checksum with sha256sum
Checksums do not match: '20fa70aefd1fdc49f4d90b74af9312e471273e54af84ca7814bf865011fb7d55' found, '4f926373f11f2a25156eee1804ec012eb912c42e5d34fc2909889da22efdadfe' expected.
Checksums match failed!
Fallback to download https://nodejs.org/dist/v5.12.0/node-v5.12.0.tar.xz
#########################################                                 58.1%^C

[ljharb]

I'm not sure I understand the initial failure - it looks like it downloaded https://nodejs.org/dist/v5.12.0/node-v5.12.0-linux-x64.tar.xz but was unable to match the checksum.

What does nvm debug print out?

[PeterDaveHello]

@ljharb I'm going to figure out the download process, something may go wrong there.

The problem can be re-produce by breaking the local cache like $ echo 123 >> node-v5.12.0-linux-x64.tar.xz

[ljharb]

All that should do is cause the file to be redownloaded - the way the process was written is that if there's anything wrong with the file, it's just replaced.

[PeterDaveHello]

oops, the other problem may came from my local patch.

[PeterDaveHello]

error message without my patch:

Downloading and installing node v5.12.0...
######################################################################## 100.0%
Computing checksum with sha256sum
Checksums do not match: '4aaad95d615190e4d68eba977ce586951f6e2d409de35e214bd5114d3ddfc6fc' found, '619fc1d14ee0c92894cf01bf1a47f5bae321ac04dfeb4cea6a2b6ce65832df79' expected.
xz: (stdin): Compressed data is corrupt
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Binary download failed, trying source.
Detected that you have 8 CPU thread(s)
Set the number of jobs to 8 - 1 = 7 jobs to speed up the build
Checksums match! Using existing downloaded archive $NVM_DIR/.cache/src/node-v5.12.0/node-v5.12.0.tar.xz

[ljharb]

ok, so that looks like it might be an issue with sha256sum perhaps?

[PeterDaveHello]

@ljharb I guess the problem came from the -C option, which will make curl trying to "continue" the download process, even on the broken file, however, I didn't find a way to recognize the half-downloading and broken file.

Removal of the broken file could solve this problem, but I also wonder if we need the "continue" option anymore? As local cache will definitely help saving the bandwidth and time, maybe -C can be dropped?

[ljharb]

On systems without the ability to verify a sha256 checksum, they still benefit from the -C option since we wouldn't be deleting the previous file.

[PeterDaveHello]

The problem here seems to be the auto-detect may not be reliable enough lol... then it caused the continued tar failed...

[ljharb]

curl's native autodetect for resuming, you mean?

If that's true, then that's a good reason to remove it.

[PeterDaveHello]

Yes, that's for resuming, but it seems to assume any file there with the same filename the same file to download, that's the problem. As we now have cache feature, once the download finished, we could usually use the cached tarball, I think that part helps more than this resuming. BTW, I didn't test the scenario on wget yet.

[ljharb]

If it comes down to it, I'm fine to remove the "resumable" part.