Please describe what you are doing to trigger the bug:
Restore from Web UI with -delete option.
Please describe what you expect to happen (but doesn’t):
Expect files not in the snapshot to be deleted, or at least for the restore to fail with an error message.
Please describe what actually happens (the wrong behaviour):
Snapshot is restored, but files not in the snapshot are not deleted.
Is there any specified filter pattern?
The Web UI doesn’t log the CLI restore command. But it does log:
2021-04-21 14:20:39.757 INFO SNAPSHOT_FILTER Loaded 1 include/exclude pattern(s)
The typical Web UI user isn’t going to be aware of the fine print about -delete being (silently) ignored if a pattern is specified (why this limitation?), or about the Web UI generating a filter pattern under the covers.
The -delete option will be ignored if you restore a single file or directory. When you select the root directory to be restored then -delete will be honored.
I understand that now, but I had to spend time figuring out why it wasn’t working, which is a diversion when one is trying to recover from a disaster. Why not at least throw an error when a command is not going to perform as requested?
Also, when restoring a root directory with -delete, does Duplicacy skip restoring files that already exist and have matching hashes?