This is possible to figure out by looking at the files duplicity stores, and thinking about how those file formats work.
Aside from some local uncompressed caching done if --archive-dir is used, all of duplicity's file storage is sent to remote hosts, and all such files are encrypted with gpg. Encrypted files are rather similar to compressed files; a bit flip in the middle of the file will make the remainder of the file fail to decompress. A CRC does allow gpg to detect which packet of the file has the error. It might be possible to recover data from packets afer the corrupt packet (as can analagously be done by bzip2recover). I'm both unsure if that would work for gpg, and I don't know if gpg'd files typically have multiple data packets. (--list-packets seems to show only one.) Now yeah, there are tar files underneath, but you'll have at worst a truncated tar file, and at best, a tar file with a big gap in it, so any tar options that handle a single bit flip seem irrelevant. -- see shy jo
signature.asc
Description: Digital signature
