Description

Range downloads might set up a wrong checksum if there isn't a checksum set. This causes problems later because a full download will send the wrong checksum and clients might flag the download even though the file was downloaded ok.

Note that range downloads might still get the checksum of the whole file, not just the downloaded piece.

In addition, appending content won't calculate a checksum.

There are some additional cases that might still need to be covered

Related Issue

https://github.com/owncloud/enterprise/issues/5457

Motivation and Context

How Has This Been Tested?

• test environment:
• test case 1:
• test case 2:
• ...

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Database schema changes (next release will require increase of minor version instead of patch)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:
• Changelog item, see TEMPLATE

Notes

• On average, range download don't generate a checksum because not the whole file is read. However, it really depends on how PHP reads the stream internally. PHP usually read blocks of 8KB and keep them in a buffer even though only a few bytes are requested and returned. This means that, for small files (less than 8KB), there is a chance that the whole file is buffered, so in this case a checksum could be stored even though, technically, not the whole file is returned.
• It's expected that, regardless of the outcome, the checksum stored in the DB is always correct. This is important taking into account the behavior of the previous point.
• While the expected actions on the data stream are expected to be easy coming from the outside (either read the whole o a part of the file, or write contents) additional actions might happen, such as overwrite a part of the stream while leaving the rest intact. In this case, a conservative approach is taken, so if there are doubts on whether we've read the whole file or the checksum could be compromised (by moving the stream pointer to a previous position, for example), no checksum will be stored because it's very likely it will be wrong.
• Partial data won't be saved among requests. This could be relevant for apps that download the file by chunks. The app could request the first megabyte, then the second, then the third... In this case, even though the file ends up being downloaded, no checksum will be stored.