Comment 8 for bug 703142

OK, I think I figured this out. Bear with me.

Duplicity keeps writing to a local partial (.part) signature file. Then when backup is done, it copies it to the remote destination using a different filename. Then it copies to its final local destination using a third filename (.gz instead of .part). Finally, it deletes the local partial.

But duplicity can be interrupted at any point during that. So when the next run happens, there are 7 possible states for a signature file, depending on when we got interrupted:

1) Incomplete local partial
2) Complete local partial
3) Complete local partial, incomplete remote
4) Complete local partial, complete remote
5) Complete local partial, complete remote, incomplete local final
5) Complete local partial, complete remote, complete local final
6) Complete remote, complete local final

But these can be collapsed a bit, because duplicity doesn't bother telling the difference between complete or not files:

1) local partial
2) local partial and remote
3) local partial, remote, and local final
4) remote and local final

Situations #2 and #3 result in this bug. #2 because next run, duplicity will sync metadata, pull down the remote into the local final slot, and we'll have three signature files. #3 because we just have three signature files already.

Attached you'll find a test script to reproduce the problem.

The fix is to be a bit smarter when sync'ing metadata. I will shortly file a merge request with a patch.