~bmerry/duplicity/pydrive-regular : changes

~bmerry/duplicity/pydrive-regular » Changes to duplicity/dup_temp.py from revision 1096

From Revision 1096 to 553

Rev	Summary	Authors	Date
1071	* Misc fixes for the following PEP8 issues: * Misc fixes for the following PEP8 issues: - E401 - see http://pep8.readthedocs.org	Kenneth Loafman	9 years ago
1070	* Misc fixes for the following PEP8 issues: * Misc fixes for the following PEP8 issues: - E231, E241, E251, E261, E262, E271, E272, E301, E302, E303, E502, E701, E702, E703, E711, E721, W291, W292, W293, W391 - see http://pep8.readthedocs.org	Kenneth Loafman	9 years ago
1065	* Merged in lp:~angusgr/duplicity/exclude-older-than * Merged in lp:~angusgr/duplicity/exclude-older-than - Add "--exclude-older-than" commandline option, that allows you to only back up files with a modification date newer than a particular threshold. * Additional pep8 cleanup.	Kenneth Loafman	9 years ago
1033	* Source formatted, using PyDev, all source files to fix som... * Source formatted, using PyDev, all source files to fix some easily fixed PEP8 issues. Use ignore space when comparing against previous versions.	Kenneth Loafman	9 years ago
975	* Merged in lp:~mterry/duplicity/2.6isms * Merged in lp:~mterry/duplicity/2.6isms - Here's a whole stack of minor syntax modernizations that will become necessary in python3. They all work in python2.6. - I've added a new test to keep us honest and prevent backsliding on these modernizations. It runs 2to3 and will fail the test if 2to3 finds anything that needs fixing (with a specific set of exceptions carved out). - This branch has most of the easy 2to3 fixes, the ones with obvious and safe syntax changes. - We could just let 2to3 do them for us, but ideally we use 2to3 as little as possible, since it doesn't always know how to solve a given problem. I will propose a branch later that actually does use 2to3 to generate python3 versions of duplicity if they are requested. But this is a first step to clean up the code base.	Kenneth Loafman	10 years ago
945	* Merged in lp:~mterry/duplicity/encoding * Merged in lp:~mterry/duplicity/encoding - This branch hopefully fixes two filename encoding issues: - Users in bug 989496 were noticing a UnicodeEncodeError exception which happens (as far as I can tell) because some backends (like webdav) are returning unicode filenames from list(). When these filenames are combined with the utf8 translations of log messages, either (A) the default ascii encoding can't handle promoting the utf8 bytes or -- if there aren't any utf8 bytes in the translation -- (B) the resulting unicode string raises an error later when log.py tries to upgrade the string again to unicode for printing. - This fix is largely implemented by adding a wrapper for backend list() implementations. This wrapper ensures that duplicity internals always see a byte string. (I'd like to eventually use this same wrapping strategy to implement generic retry support without backends having to add any logic, but that's just a thought for the future.) - That is, the fix for issue #1 is completely inside backend.py and the changes to backends/*.py. - The rest of the invasive changes deal with filenames that may not be valid utf8. This is much rarer, but possible. For proper handling of this, we need to print using unicode, and convert filenames from the system filename encoding to unicode, gracefully handling conversion errors. Some of the filenames we print are remote names. Who knows what encoding they are in; it could be different than the system filename encoding. 99% of the time, everything will be utf8 and we're fine. If we do get conversion errors, the only effect should be some question mark characters in duplicity logging output. - I tried to convert as much of the actual codebase to use unicode for printing. But I stopped short of adding an assert in log.py to enforce unicode, because I didn't want to go through all the backend code and manually adjust those bits without being able to test each one.	Kenneth Loafman	10 years ago
903	* Merged in lp:~mterry/duplicity/static-corruption * 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.	Kenneth Loafman	11 years ago
869	- Merged in lp:~mterry/duplicity/ropath.index - Merged in lp:~mterry/duplicity/ropath.index + This branch does two main things: 1) Skips base dir entries when compiling the list of deleted delta iters. (this gracefully recovers from the sort of situations that lead to bug 929067). I'm reasonably confident this is an uninvasive change, but please confirm. 2) Overwrites the sigtar file on backup-restart. This is because AFAICT, duplicity will rewrite the entire sigtar each restart. But we were opening the sigtar file as "ab", so we'd just dump the contents on top of the previous contents. Which was causing some confusion in bug 929067. If I'm wrong that we don't always rewrite the entire sigtar each time, this needs some rethink. Please also confirm that. + In addition, I added two tests for the above two changes and make some improvements elsewhere in the restarttest.py file while I was at it.	Kenneth Loafman	11 years ago
790	739438 Local backend should always try renaming instead of c... 739438 Local backend should always try renaming instead of copying	kenneth at loafman	12 years ago
783	Merged in lp:~mterry/duplicity/tarfile Merged in lp:~mterry/duplicity/tarfile	Kenneth Loafman	12 years ago
773	- Ignore ENOENT (file missing) errors where it is safe. - Ignore ENOENT (file missing) errors where it is safe. - Set minimum Python version to 2.4 in README.	Kenneth Loafman	12 years ago
749	797758 Duplicity ignores some FatalErrors 797758 Duplicity ignores some FatalErrors	Kenneth Loafman	12 years ago
748	Checkpoint Checkpoint	Kenneth Loafman	12 years ago
721	433591 AttributeError: FileobjHooked instance has no attrib... 433591 AttributeError: FileobjHooked instance has no attribute 'name'	Kenneth Loafman	13 years ago
680	Merged lp:~ed.so/duplicity/survive_spaces. Merged lp:~ed.so/duplicity/survive_spaces.	Kenneth Loafman	13 years ago
656	567738 --ssh-options options passing options to ssh do not ... 567738 --ssh-options options passing options to ssh do not work	Kenneth Loafman	13 years ago
631	Fix real errors found by PyLint. Remove unneeded includes. ... Fix real errors found by PyLint. Remove unneeded includes. Tag spurious errors so they don't annoy.	ken	14 years ago
626	Merged in lp:~duplicity-team/duplicity/po-updates Merged in lp:~duplicity-team/duplicity/po-updates	ken	14 years ago
555	Fix Bug #395826 "No such file or directory" when backing up ... Fix Bug #395826 "No such file or directory" when backing up second time	Kenneth Loafman	14 years ago
553	Fix bug #394629 Hang on first collection-status Fix bug #394629 Hang on first collection-status	Kenneth Loafman	14 years ago

Older »