I think that’s just because there’s one message for both. I’m not a web developer, but I think it’s here:
I mentioned this in a comment on an issue, but feel free to file a new Issue to get it in the queue.
The easy fix would be to make the message generic to cover both types. Customizing is harder.
I suppose if there were two, “Stop now” one could state the message about file uploading again.
Stop now results in “Detected non-empty blocksets with no associated blocks!” #4037
Stop nowwould announceStop after current file, which is kind of the wrong stop type
Presumably file uploads mentioned in below.
Short of killing the process, I don’t think you can. Hard stops may leave messes. Backups dislike those.
Duplicati does try to recover from unexpected hard interruptions (e.g. power failure), but recovery won’t happen until next backup run. At that next time, it uploads a synthetic file list covering what it got that far.
After that, backup runs, avoiding second uploads of source file blocks that it finds are already uploaded.
I wouldn’t recommend killing Duplicati on purpose though, as I don’t think the recovery from it is perfect.
You can maybe make “Stop now” (misleading name, but what to say – and then what to call the other?) slightly faster by making asynchronous-upload-limit smaller (e.g. 1), but short queue may slow backups.
I haven’t timed all of the speedups-of-stop/slowdowns-of-backup I offer here, but you could time them…
Setting a small Remote volume size will reduce the queued data, but may be slow for a very big backup.
I’m not sure how fast your upload is, but on my rather slow link, I can probably upload a 50 MB dblock in about 90 seconds. This gets slow when uploads run in parallel, but that speed-booster can be disabled:
--asynchronous-concurrent-upload-limit (Integer): The number of concurrent
uploads allowed
When performing asynchronous uploads, the maximum number of concurrent
uploads allowed. Set to zero to disable the limit.
* default value: 4