lp:~mterry/duplicity/pygi

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:duplicity/0.6 at revision 906

duplicity-team: Pending requested 2013-01-15

Diff: 187 lines (+42/-33)

1 file modified

duplicity/backends/giobackend.py (+42/-33)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

905. By Michael Terry on 2013-01-15

Use PyGI instead of older pygobject style for gio backend

904. By Michael Terry on 2013-01-11

Add auto-ctrl-c-test.sh to help stress-test restart 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.

902. By Kenneth Loafman on 2013-01-02

* Fixed 1091269 Data corruption when resuming with --no-encryption
  - Patches from Pascual Abellan that make block size consistent and
    that add no-encryption option to manual-ctrl-c-test.sh.
  - Modified gpg.py patch to use 64k block size so unit test passes.

901. By Kenneth Loafman on 2013-01-01

* Merged in lp:~ed.so/duplicity/u1_and_manpage
  - Manpage
    - document Ubuntu One required python libs
    - added continuous contributors and backend author notes
  - U1backend
    - lazily import non standard python libs, fixes
    http://article.gmane.org/gmane.comp.sysutils.backup.duplicity.general/5753
    - fix "not bytearray" prevents PUT with python 2.6
    - don't hang after putting in credentials (cause it silently retries in background)
      but go through with backup

900. By Kenneth Loafman on 2012-12-22

* Merged in lp:~ed.so/duplicity/manpage
  - Clear up PASSPHRASE reusage as sign passphrase. Minor fixes.

899. By Kenneth Loafman on 2012-12-22

Merge changes from trunk.

898. By Kenneth Loafman on 2012-12-22

* Merged in lp:~ed.so/duplicity/webdav.fix-retry
  - bugfix: webdav retrying broke on ERRORS like "error: [Errno 32] Broken pipe" in
    socket.pyas reported here https://answers.launchpad.net/duplicity/+question/212966
    added a more generalized 'retry_fatal' decorator which makes retrying backend
    methods even easier

897. By Kenneth Loafman on 2012-11-22

Nuke tabs.

896. By Kenneth Loafman on 2012-11-19

* Merged in lp:~ed.so/duplicity/lftp.netrc
  - Allow .netrc auth for lftp backend
* Merged in lp:~mterry/duplicity/946988
  - This fixes bug 946988 by not duplicating the checks for when we should ask
    for the password (those same checks are done more correctly inside
    get_passphrase). And add a test to reproduce the bug.