collection-status slower with full cache than with empty cache

[Mahdi Mokhtari]

Running `duply duplitest status` (which runs duplicity collection-status) takes a bit over 2 minutes, removing the files from the cache directory and running `duply duplitest status` again, it only takes one second to run. I would consider the opposite effect to be logical, e.g. having to download all the cache files from the backup target location (which is in file:///tmp, btw), but it seems, duplicity simply skips over the part where it looks into the manifest files etc, if they aren't there and just enumerates the files from the outside (looking at the target location) to create the collection status.

Two logs are attached as test-cases and proofs.
The tested version is 0.7.12 on FreeBSD 10.3
(Naturally, The attachments are anonymized :D)

[Kenneth Loafman (kenneth-loafman)]

What you are seeing is the difference between having the cache already synchronized versus having to resync the local cache from the remote store. It has nothing to do with the cache name.

[Kenneth Loafman (kenneth-loafman)]

* Patched in lp:~dawgfoto/duplicity/skip_sync_collection_status
  - collection-status should not sync metadata
  - up-to-date local metadata is not needed as collection-status is
    generated from remote file list
  - syncing metadata might require to download several GBs