darksonn / backblaze-b2-rs Goto Github PK

In the module level documentation for each module there are links to various structs that use relative urls. Since the doc for the module is embedded on the index, which is in another folder, this causes broken links.

Now that I started using this library I can provide some feedback.

The API is somewhat weird. There is a lot of generics in it, that I don't really know what to do with (other than figure out how to make compiler happy). The fact that I have to provide a hyper::Connector seems kind of weird. Occasional lifetimes seem needless, as in a library like this a clone of small things here and there seems irrelevant in comparison to network transfers.

Currently because of hyper api limitations it is not possible to specify the info to be stored with the file. Maybe I should make the user pass the hyper headers for that directly.

Hi,

This is a really nice crate! I was looking through the documentation, and it is really well done. I wish the "higher-level" API was available, but the "raw" one is actually exactly what I would expect.

I have a couple of questions.

Is multi-threaded usage working well? I plan to employ a thread-pool, so just double checking.

Are you aware if keepalive is working? I'm looking at https://www.reddit.com/r/rust/comments/6zm1uq/backblaze_reqwest_and_keepalive/ and for rdedup it is going to be very important to be able to efficiently upload many, many small files. Having a working keep-alive could keep the link saturated, even with many very small files being uploaded.

Do you think there are any other things (especially any current shortcomings) that I should be aware of?

Anyway, thank you very much for this crate, it will make my task much easier!

B2 allows uploading by providing the SHA1 at the end of the upload, this is very useful for servers that want to offload user uploaded files to b2 by directly streaming the file being uploaded instead of first uploading the whole file to the server and then computing the SHA1 before uploading to b2:
https://www.backblaze.com/b2/docs/uploading.html
Is there a plan to support this in this lib? It would be easy to implement.
The API in this lib could be similar to the b2 API:
There would be a function similar to this:

fn upload_file_sha1_at_end<InfoType, R: Read, C, S>(
    &self, 
    file: &mut R, 
    file_name: String, 
    content_type: Option<Mime>, 
    content_length: u64, 
    connector: &C
) -> Result<MoreFileInfo<InfoType>, B2Error> 

And it just forwards the reader, i.e. assumes that the last 40 bytes are the SHA1.

The alternative would be to change upload_file() to take content_sha1: Option<String> but that'd be more ambiguous, people might think not providing the SHA1 would be equivalent to X-Bz-Content-Sha1: do_not_verify.
(Btw, maybe that should also be supported, then this should mean that, IMO.)

Hi,

It seems this library uses a version of the library base64 which is vulnerable to security issues. Please refer to https://github.com/RustSec/advisory-db/blob/master/Advisories.toml#L53 .

patch commit : marshallpierce/rust-base64@24ead98
patched version : [">= 0.5.2"]
used version : ["~0.5.0"]

This is done using crates.io data. Feel free to close this issue if it's not relevant.

Thanks

Server-side copying was missing for a long while, but is now available. https://www.backblaze.com/b2/docs/b2_copy_file.html

I also wanted to check if you're still around. It's been a while since the last commit/release.

When logging in with an application key, the b2_authorize_account call returns an accountId field. This has to be used as the accountId parameter of the b2_list_buckets call, but currently the key ID from B2Credentials.id is used. This then leads to an "accountId invalid" error. (Maybe application keys weren't around yet when the library was written.)

The error type needs to be enhanced to more easily specify what kind of error occurred. Specifically I would like that at least the following events to have their own value in the error enum:

• Authentication has expired
• Invalid authentication
• Incorrect sha1 checksum

The last one should probably be in its own error type as well.