Please describe what you are doing to trigger the bug:
Pruning a remote storage (which is a Copy of a local one).
duplicacy_win_x64_2.2.3.exe -log prune -keep 0:30 -threads 4 -all -storage offsite
Belonging to a series of steps. Daily:
machines.BACKUP to local_server
In server.local, weekly:
server.PRUNE local server.PRUNE offsite server.COPY local to offsite
Please describe what you expect to happen (but doesn’t):
Old snapshots get deleted.
Some form of automatic recovery of corrupted chuncks.
Please describe what actually happens (the wrong behaviour):
ERROR DOWNLOAD_DECRYPT Failed to decrypt the chunk BIG_HASH: The storage doesn’t seem to be encrypted.
COPY to offsite, succeeds, but PRUNE offsite still fails with same error.
CHECK -a -tabular, same error in the same chunck.
Searched for the file on offsite storage, it existed but was all “00 00 …”.
(There was a *.fsl with same name and non-00 content.)
PRUNE offsite, success, with log:
WARN DOWNLOAD_RESURRECT Fossil SAME_BIG_HASH has been resurrected
In the meantime the consumed storage kept increasing because of 3 months without prunes.
If it was this easy for duplicacy to recover a non-existent file, shouldn’t it try to repair the original 00’ed chunck failing to decrypt?
Keep up the good work!!