The delete (and prune) operations on --dry-run currently report 0B of "Deleted data"; that borg accepts those arguments together is considered an error and being worked on at #4373 on grounds that it could not run fast.

I suggest that --dry-run and delete/prune should take its time to work through what would be deleted, which might take just as long as the full thing but be non-destructive. (Possibly gated by a flag that allows slow operations, or only gated by the --stats flag given that whoever requested the stats probably just wants what this is about).

The use case for this is to judge the effectiveness of changes to the pruning policy – say approaching disk space limits and want to know whether it'll do me any good to decrease the number of daily backups or whether I need to delete old monthlies, or on which repositories that would actually do any good.

Judging from the discussion in #4373, implementing this would not only mean actually calculating the to-be-freed parts, but also to persist the information of what-would-already-be-gone between the distinct invocations of delete that result from a prune.

Have you checked borgbackup docs, FAQ, and open Github issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

It's an issue, but out of the scope of currently documented behavior, thus classified as wishlist item.

System information.

borg 1.1.9

Full borg commandline that lead to the problem (leave away excludes and passwords)

borg delete -v --stats --dry-run chrysn@prometheus:hephaistos.borg::chrysn-full-2016-11-29-18:26