lp:~townsend/duplicity/fix-1161599

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:duplicity/0.6 at revision 912

edso: Approve on 2013-04-21

Diff: 34 lines (+6/-1)

1 file modified

duplicity/backends/u1backend.py (+6/-1)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Bug #1161599: Backup to Ubuntu one failed, after 5 attempts status 400 bad request

Medium

Fix Released

Link a bug report

Related blueprints

912. By Christopher Townsend on 2013-04-19

* Fixes the case where the file pointer to the backup file was not being set back to the beginning of the file when an error occurs. This causes subsequent retries to fail with 400 Bad Request errors from the server. This is due to a change in revno. 901 where a file handle is used instead of a bytearray.
* Fixes the removal of Content-Length from the header in revno. 901. Content-Length is required according to the Ubuntu One API documentation.

911. By Kenneth Loafman on 2013-02-18

* Merged in lp:~ed.so/duplicity/verify.data
  - add switch --compare-data, to selectively enable formerly always disabled
    data comparison on verify runs

910. By Kenneth Loafman on 2013-02-17

* Merged in lp:~jnoster/duplicity/dpbx-added
  - Add Dropbox backend
  - NB! In order to use the backend one must:
    1. Install Dropbox Python SDK first.
    2. Run the duplicity with Dropbox backend (dpbx://) first time
       *interactively* to catch and follow the oAuth URL.

909. By Kenneth Loafman on 2013-02-17

* Applied patches from Laszlo Ersek to rdiffdir to "consume a chain of sigtar
  files in rdiffdir delta mode" which supports incremental sigtar files.

908. By Kenneth Loafman on 2013-01-23

* Merged in lp:~duplicity-team/duplicity/po-updates
  - Updated translations

907. By Kenneth Loafman on 2013-01-18

* Merged in lp:~mterry/duplicity/py3rsync
  - This branch lets one build the _librsync module with Python 3. You can't
    really do anything useful with it, but it's a nicely-isolated piece to add
    Python 3 support for.
  - The changes are a mix of modernization and #ifdef logic.
  - All tests still pass in Python 2.7 and 2.4. I tested manually that the module
    worked as expected in Python 3.

906. By Kenneth Loafman on 2013-01-18

* Merged in lp:~mterry/duplicity/pygi
  - Python bindings for the gobject stack (used in the gio backend) have changed
    from static to dynamically-generated bindings. The old static bindings are
    deprecated. So here's a branch to change the gio backend from old to new ones.

905. By Kenneth Loafman on 2013-01-18

* Merged in lp:~ed.so/duplicity/webdav.manpage
  - explanation of webdav changes above

904. By Kenneth Loafman on 2013-01-18

* Merged in lp:~ed.so/duplicity/webdav.fix-retry
  - added ssl certificate verification (see man page)
  - more robust retry routine to survive ssl errors, broken pipe errors
  - added http redirect support

903. By Kenneth Loafman on 2013-01-08

* Merged in lp:~mterry/duplicity/static-corruption
  - This branch fixes three possible ways a backup could get data-corrupted.
    Inspired by bug 1091269.
      A) If resuming after a volume that ended in a one-block file, we would
         skip the first block of the next file.
      B) If resuming after a volume that ended in a multi-block file, we would
         skip the first block of the next file.
      C) If resuming after a volume that spanned a multi-block file, we would
         skip some data inside the file.
  - A and B are because when finding the right place in the source files to
    restart the backup, the iteration loop didn't handle None block numbers
    very well (which are used to indicate the end of a file).
  - C is what bug 1091269 talks about. This was because data block sizes would
    get smaller as the difftar file got closer and closer to the volsize.
    Standard block sizes were 64 * 1024. But say we were close to the end of
    the difftar... When resuming, duplicity doesn't know the custom block sizes
    used by the previous run, so it uses standard block sizes. And it doesn't
    always match up, as you can imagine. So we would leave chunks of data out
    of the backed up file.
  - Tests added for these cases.
  - This branch is called 'static-corruption' because all these issues occur
    even when the source data doesn't change. I still think there are some
    corruption issues when a file changes in between duplicity runs. I haven't
    started looking into that yet, but that's next on my list.
  - C only happened without encryption (because the gpg writer function already
    happened to force a constant data block size). A and B happened with or
    without encryption.