Please describe what you are doing to trigger the bug:
Duplicacy starts a backup job as intended on 2020-09-06 17:52:33.940 and this is revision 4.
Please describe what you expect to happen (but doesn’t):
I expect the “revision 4 created at” date on the restore tab to match the date above
Please describe what actually happens (the wrong behaviour):
The “revision 4 created at” date on the restore tab is 2020-09-03 23:03 and this is the wrong date.
What does the backup job say about the starting time and ending time?
The log says it started it 2020-09-06 17:52:33.940 and ended at 2020-09-06 17:53:00.963
I think I may be able to suggest a cause. I deleted some revisions using cli because I was doing some testing and I had ran a fair few backup jobs in short succession which I wanted to clean up. Although there were gone in the GUI, it appears Duplicacy is reusing the dates from the revisions I deleted.
Does that give you any useful info?
edit 07-09-2020: I can confirm what is happening:
Duplicacy is definitely reusing the timestamps from the revisions I deleted using the CLI. I just ran a manual backup (creating revision 5) and I get 2020-09-03 23:07. I was able to compare the dates with those in the “.duplicacy-web\stats\schedules” directory and it is an exact match.
Is it possible to repair this?
That is because the revision files stored in the cache of the web GUI became stale after you deleted those revisions using the CLI. You can fix it by removing the entire cache directory under .duplicacy-web/repository/localhost*/.duplicacy/cache.
Hmm I see. So one should refrain from using the CLI except for read actions? Or should I have issued a different command to get rid of the revisions?