Then it would be wrong if Repair is changed so it won’t do that. It will now, which is bad.
What’s worse is it’s hard to find out what the files are. You can look at live log if need be.
There’s a certain amount of reconciling at the start of the backup while checking file listing.
A file meant to be deleted had been set to Deleting state in the database. If backend didn’t
actually delete before, it will get another chance then.
Changed Computer Clock For A Few Minutes and Broke Duplicati
is one report of how Duplicati deals with bad clocks. I don’t think it happens much though…
There’s probably some discussion on that around. It happens. Possibly a similar sanity test
could avoid problem from that, e.g. if someone decides to Repair. Chances are the dlist file
times are wildly different from the Remotevolume records, and that would be a good clue…
Putting Repair button under Database → Maintenance could certainly give that impression.
Arguably some cases use database information to “fix” remote (see below), but who knew?
It’s not just a button problem. The REPAIR command describes how it does different things.
In addition to deleting “extra” files, a repair can sometimes replace lost dlist and dindex files.
And possibly it also fixes internal database problems, but details on what it does are scarce.
Even ignoring compatibility pains, I don’t think there’s much chance of getting repair redone.
Message changes are likely easier, but bear in mind that non-English versions take awhile…
I also think the original proposal was to rely less on user, and more on looking situation over.
The challenge may be balancing preventing accidents against impeding legitimate activities.