No, I don’t think it would, since at the moment
-all - some of those columns, like unique and new, need to know about all the revisions in the storage.
I dunno if it’s worth allowing a subset of snapshots to be
checked in this way. Perhaps it’s safer, and not all that more resource intensive, to simply check
-all snapshots and chunks. After all, Duplicacy has to ListAllFiles() on the storage anyway.
Though I guess you could use
-last n to do it slightly differently - work out the differential of chunks created with n days and just check the existence of those chunks one-by-one, though it’s a less-safe form of
Also, I don’t know how
check is implemented, but strictly speaking, the second half of the process which does the stats/tabular, shouldn’t necessarily require a physical check for all chunks beforehand. Maybe in the existing implementation the stats are built from the list of chunks it has in memory after checking those chunks exist, but the same information could be built from iterating over all the revision metadata without doing that check. i.e. you could separate out the stats and check operations.
Anyway, I’d propose that
-last n - in the case of check, or copy (which I’m most eager to see such a flag) - would always do the last revision plus any snapshots created within n days. Then you wouldn’t have to specify an extra day (21) just in case? If you accidentally skipped jobs, or your PC has been off for a good while,
-last n would always include 1 revision minimum, just as
-last on its own would.