I suspect that cloud services typically don’t keep partially uploaded files, but the question is whether the Duplicati viewpoint sees it as uploading, then a failure happens, then it decides to delete. States run like
Duplicati’s marking scheme is (in part) shown above, and an old (2015) description of the flow is here.
Current code may or may not follow 2015 description, but this is some of the delete-fail recovery logic:
and ultimately the proof of behavior is what is seen. I’ve seen some unexpected behavior in the above (unable to supply additional details, but I have a failure test program and some run notes somewhere).
( $50 Bounty ) Attempting deletion of files before retention span is over would need to be explained too.
Without actually seeing the database, it’s not certain what happened, but one known behavior is that at Duplicati backup start, it cleans up files that it was trying to delete on a previous run, i.e. state Deleting.
I actually make use of this to fix a problem that comes up when Compact is interrupted and it forgets it successfully deleted some dindex files. Doing a database transaction rollback is the suspected cause. Workaround is to set state of the dindex files to Deleting, which is what the no-issue dblock files had.
If you’re willing to dig in code more, feel free to take this to GitHub Issues to see if a developer can chat. There’s a major shortage of developers though, so an even better course would be to do a pull request.
There have been several forum user attempts to work with immutable destinations, and possibly even more attempts to work with cold storage, where I’m not sure if the retry delete may present a problem.
The destination does what it does. Duplicati knows a few capability differences, but has to deal with all.
If you want to poke at this more, beyond just reading code, an SQLite browser helps, and I can offer a script to make upload errors, to look at retry handling. That’s the test I tried awhile ago that I mentioned.