--max-retries

[eburcat]

Currently the retries are hard-coded to 5.
It'd help if it was possible to control the number of retries, especially when we're throttling our traffic and we're trying to upload big files.
If it was possible to set the value to somewhere in the range of 1 to 30 I think it can be reasonable in some cases.

[fviard]

I don't think that a lot of people would use this option but that looks ok to me to add that in config options.

[lfdnas]

It would be great to have this feature in case of failure!

[sebastiandanconia]

A --max-retries option could be part of a successful solution to my problem.

I use an S3-compatible private cloud which I access over a less-than-reliable connection that is extremely slow in relation to the size of the data I'm sending (> 1TiB over 1.25 MB/s, which takes weeks or more). Meanwhile, the server's network connection goes down almost weekly.

Currently, s3cmd increases the timeout duration linearly based on the retry number. My preferred backoff intervals would be a few seconds in the beginning, then increase to a maximum of 10-20 minutes or so between retries, finally giving up after 3 days or so. The --max-retries option is reasonable, but I additionally advocate tuning the backoff/retry timeout function so it's reasonable for a really long retry window before s3cmd gives up.

I'm willing to try coding up a solution once I have clarity on what kind of Pull Request you'd accept. I was thinking of adding a concept of "retry profiles" in the config file: retry_profile = normal, retry_profile = aggressive, etc., and tuning the client's behavior accordingly.

[fviard]

A "--max-retries" option was added in MASTER.
(But still anything like retry_profile for the moment).