Release: 2.1.0.102 (Canary) 2024-12-12

[kenkendk]

@Folgore101

It tells me there is a version 2.1.0.103 but it can’t find it.

That was my mistake. The build failed near the end, so I restarted it, not seeing that the counter had incremented. I rebuilt everything with the 2.1.0.2 version number, but it looks like the manifest file was not overwritten with the correct number.

@ollibraun

Unfortunately, the read-write-timeout option does not change this behavior. It may well be that the abort message always comes after 30 seconds, even if the option is set to one hour.

Thanks for trying this and reporting the result.

I figure out why it fails for MSGraph-based backends: the download waits for the entire file to be downloaded before streaming it. This causes some issues with UI not showing progress, etc, but also triggers the timeout issue.

There are two workarounds for 2.1.0.102:

• set --disable-streaming-transfers=true which will skip the timeout stream
• set --use-http-client=false which will work with the timeout

It should also be possible to get it working by disabling the timeout with:

--read-write-timeout=0s

But since you report that setting a 1h timeout does not work, I am not 100% sure why setting the timeout does not work for @ollibraun . Did you set it in the backup job advanced options? It does not work setting it as a startup parameter, but you get no warnings if you do.

EDIT: The code always applies 30s timeout, regardless of how you set it . I have a fix for that.

I will continue to debug this a bit more and see if I can make it more smooth. The timeout for the upload is not working correctly with large files, due to the way MSGraph is chuncking and delaying operations.

EDIT: PR is ready for fixing the msgraph issues.