Skip to content

Fix large file resume refusing the large_file_sha1 it stored (#223) - #232

Draft
sophiecarreras wants to merge 1 commit into
masterfrom
fix-large-resume-sha1-key
Draft

sophiecarreras wants to merge 1 commit into
masterfrom
fix-large-resume-sha1-key

Conversation

@sophiecarreras

Copy link
Copy Markdown
Contributor

Fixes #223

Problem

finishUploadingLargeFile (and any other resume of a started large file) threw a local B2LocalException for a large file whose content source knows its sha1:

contentSource has fileInfo '{ }', but largeFileVersion has '{ large_file_sha1=... }'

The request that started the file was refused when it was repeated.

When the content source knows its sha1, the SDK stores it in the large file's file info under the key large_file_sha1 (B2Headers.LARGE_FILE_SHA1_INFO_NAME). B2LargeFileUploader.throwIfLargeFileVersionDoesntSeemToMatchRequest checks that value as the sha1, and removes it from the stored file info before comparing the rest with the request's file info. It removed B2Headers.LARGE_FILE_SHA1, the X-Bz-Info-large_file_sha1 header form, which is not a key of that map, so the entry stayed and was reported as unexpected file info.

Fix

Remove B2Headers.LARGE_FILE_SHA1_INFO_NAME instead. Any other file info entry still has to match. Adds a ### Fixed entry to the changelog.

Tests

In B2LargeFileUploaderTest:

  • testThrowIfLargeFileVersionDoesntSeemToMatchRequest_matchingSha1IsNotAFileInfoMismatch: a stored large_file_sha1 equal to the content source's sha1 is accepted. Fails without the fix (throws B2LocalException), passes with it.
  • testThrowIfLargeFileVersionDoesntSeemToMatchRequest_otherFileInfoStillMismatches: a stored file info entry other than large_file_sha1 still causes a mismatch. This passes with and without the fix; it guards against the fix removing more than the one key.

I also updated the comment in .sdkharness/tests/conformance/LargeResume.java, which described the refusal as the current behavior.

Verification

  • ./gradlew test (all modules, includes check_code): build successful, 722 tests, 0 failures, 0 errors.
  • The large.resume conformance check in .sdkharness, run against a local B2 simulator, interrupts a large upload after two parts and then calls finishUploadingLargeFile with the same content, with and without a known sha1. On master it fails on the sha1 leg with the mismatch error above; with this change it passes.

B2LargeFileUploader removed the header form of the key (X-Bz-Info-large_file_sha1) from the stored file info before comparing it with the request's, but the stored key is large_file_sha1. finishUploadingLargeFile therefore threw a local mismatch error for a large file whose content source knows its sha1.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Resuming a large file is refused when its fileInfo carries large_file_sha1

1 participant