Okay, I did it and it went a lot faster now, but it is difficult to say whether that was because it was no longer the first time I ran prune (though none of the previous runs was successful) or because of the multi-thread. I also used -log which I failed to do earlier.
And being able to look at the log, a few more questions arise:
Duplicacy should be more talkative
PS C:\> duplicacy -log prune -r 20 -threads 6 -storage pcloudwebdav
2018-09-19 09:35:41.529 INFO STORAGE_SET Storage set to webdav://<myusername>@webdav.pcloud.com/Backup/Duplicacy
2018-09-19 09:43:01.884 INFO SNAPSHOT_DELETE Deleting snapshot ALPHA_C at revision 20
2018-09-19 09:54:45.291 WARN CHUNK_FOSSILIZE Chunk 3d58ffa679ede7257e6581da4c040dd9b7969cb158e45dc04d27f353a3e37c52 is already a fossil
2018-09-19 09:54:45.448 WARN CHUNK_FOSSILIZE Chunk 5e530ad112d412eee874d244b1e574c3bb4eaa58d0c5d44dc68759d55e8ea796 is already a fossil
What was duplicacy doing between 09:35:41.529 and 09:43:01.884? And then between 09:43:01.884 and 09:54:45.291?
In the case of the second empty time period, I’m guessing that it was fossilizing chunks. But it doesn’t seem plausible to me that Chunk 5e530ad112d412eee874d244b1e574c3bb4eaa58d0c5d44dc68759d55e8ea796 is already a fossil would be classed as a warning, while the actual act of fossilizing a chunk that was not a fossil previously is not communicated at all. If one should be ranked more critical than the other, then, surely, fossilizing would be more critical than finding out that something has already been fossilized, right? But I don’t think either is worth a warning at all. Both should be classed as INFO.
At the very least, both acts should be logged. Just like in the backupcommand where both uploaded and skipped junks are logged as INFO.
More generally, whatever duplicacy was doing during those silent periods, I think it should talk about it. In fact, I’d like to suggest that 7 minutes of silence is bad UX in any command, not just prune. It would be great if duplicacy would default to printing an update at least once per minute, if -log is used, of course. If -log` isn’t used, I would nevertheless deem it good practice that it at least responds with an acknowledgement of the command and a hint that this may take some time. Something like
PS C:\> duplicacy prune -r 20
Storage set to webdav://<myusername>@webdav.pcloud.com/Backup/Duplicacy
Starting pruning. This may take a while...
Currently it only confirms the storage, not the start of the operation would like to raise
Check for latest revision immediately
Another issue I would like to raise (and which is more on topic here) relates to this:
PS C:\> duplicacy prune -r 20 -storage pcloudwebdav
Storage set to webdav://<myusername>@webdav.pcloud.com/Backup/Duplicacy
The latest snapshot ALPHA_C at revision 20 can't be deleted in non-exclusive mode
This was my very first try at deleting revision 20. Unfortunately, I forgot the -log option so we don’t have the times, but I can tell you that it took at least 30 minutes, possibly several hours, before duplicacy concluded that it cannot delete the revision.
If I understand the message correctly, the reason why it could not be deleted was simply that it was the latest revision. Fine. But why does it not tell me so immediately? It seems to me that the order of things needs to switched around: First check if revision is latest and abort if so, then start downloading snapshot meta data. Currently it seems to be the other way around.
