Find a topic related to this from June :
I look around a bit more and might have mistaken.
The hard mode seem to be triggered by :
bytesUntilLimit = acc.values.max - acc.stats.GetBytes()
From
// of bytes remaining to read.
func (acc *Account) checkReadBefore() (bytesUntilLimit int64, err error) {
// Check to see if context is cancelled
if err = acc.ctx.Err(); err != nil {
return 0, err
}
acc.values.mu.Lock()
if acc.values.max >= 0 {
bytesUntilLimit = acc.values.max - acc.stats.GetBytes()
if bytesUntilLimit < 0 {
acc.values.mu.Unlock()
return bytesUntilLimit, ErrorMaxTransferLimitReachedFatal
}
} else {
bytesUntilLimit = 1 << 62
}
// Set start time.
if acc.values.start.IsZero() {
acc.values.start = time.Now()
}
acc.values.mu.Unlock()
return bytesUntilLimit, nil
}
Incorrect soft mode is enforce by that :
fs.Config.MaxTransfer >= 0 && (accounting.Stats(ctx).GetBytes() >= int64(fs.Config.MaxTransfer)
- fs.Config.MaxTransfer : from the command argument not the account
- accounting.Stats(ctx).GetBytes() : Bytres from succesfull transfered files
If so instead of returning ErrorMaxTransferLimitReachedFatal would it be preferable to only remove the new transfert with a message like 'Skip Already Reach max transfert limit' ? When no more file in queue, it will gracefully stop when other files are done. This way, it will correct cautious also, by accepting file that are small enough instead of erroring on the first one.
What do you think ?
PS : haven't figure out why the ErrorMaxTransferLimitReachedFatal cancel other transferts...