We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The user usually calls Download.Read(p []byte) (n int, err error) in a loop. Currently at the boundary between two segments one call returns 0 bytes.
Download.Read(p []byte) (n int, err error)
This causes bugs and additional complexity for library authors and users. Example:
storj-thirdparty/nextcloud-app#4 / storj-thirdparty/uplink-php#12 storj/uplink-java#10
I propose we change the behavior so that Download.Read() never returns 0 bytes, unless there are no more bytes left to download.
I'm not sure where this behaviour actually emerges and should be changed. Maybe somewhere in storj.io/common/ranger.concatReader or storj.io/common/readcloser.multiReadCloser.
The text was updated successfully, but these errors were encountered:
An easy fix would be to retry in the top-level download implementation.
Sorry, something went wrong.
Oh, also, it could also be a side-effect of avoiding to return error and read 0 bytes from some internal read. (I'm not sure, but I think we had that property in https://github.com/storj/uplink/blob/main/private/piecestore/download.go#L114)
read 0
@Erikvv does the uplink-c library return an error (specifically EOF) when the 0 bytes are returned at the boundary between 2 segments?
@ifraixedes No there's no error, EOF is only at the end of the object (or requested range).
No branches or pull requests
The user usually calls
Download.Read(p []byte) (n int, err error)
in a loop. Currently at the boundary between two segments one call returns 0 bytes.This causes bugs and additional complexity for library authors and users. Example:
storj-thirdparty/nextcloud-app#4 / storj-thirdparty/uplink-php#12
storj/uplink-java#10
I propose we change the behavior so that Download.Read() never returns 0 bytes, unless there are no more bytes left to download.
I'm not sure where this behaviour actually emerges and should be changed. Maybe somewhere in storj.io/common/ranger.concatReader or storj.io/common/readcloser.multiReadCloser.
The text was updated successfully, but these errors were encountered: