Thank you very much for your help and explanations. I will continue using rdiff-backup but without the (unimportant) folder with the long filename file.
I don't have the skill to fix that bug, but hope that Sol1 takes care. I will keep my old backup in case it could be useful for debugging/testing. Please, let me know if I can help. Cheers, Michael Am 23.08.2016 um 21:29 schrieb Joe Steele: > On 8/23/2016 7:12 AM, Michael Born wrote: >> I checked my rdiff-backup (version 1.2.8-22.1.4) which was from my main >> repository. >> I now switched to the official Archiving repository and got the version >> 1.2.8-42.5 >> I have to admit that I can't see what patches are in what version > > You'd need to look at the source rpm to see the patches. I had looked > at the 1.2.8-42.5 rpm and saw that it had the patches. You could also > look at the installed code (rdiff_backup/rpath.py) and see if it has > been patched. > >> (your >> linked rdiff-backup-1.2.8-sparse-no-seek-in-gzip.diff shows a Date: >> 2016-06-29 but in the overview they say it was changed about 2 years >> ago). >> > > I was puzzled about that 2016 date as well. It must be a typo. > > I knew this gzip 'Negative seek in write mode' issue was sounding > strangely familiar: > > https://lists.nongnu.org/archive/html/rdiff-backup-users/2015-12/msg00006.html > > > >> I'm fine with my messed up backup. I already created a new one and don't >> rely on the old one. >> >> But what happens with the bug you identified? Will that one be >> officially fixed? Should I file a bug report somewhere? (Your github >> issue has all in it already) >> > > Who knows when/if it will be fixed. That would obviously require > someone with the skills, time, and inclination to volunteer. Very > serious bugs and and bugs that are simple to fix are likely to be > addressed more quickly (at least unofficially within the distros that > provide the package). > > Bugs used to be reported at: > > http://savannah.nongnu.org/bugs/?group=rdiff-backup > > But then there was an announcement that Sol1 was taking over official > maintainership of rdiff-backup: > > https://lists.nongnu.org/archive/html/rdiff-backup-users/2016-02/msg00009.html > > > That's the main reason I created the issue on github. > > Sol1 has also created a simple web page with links to github which I > hadn't seen before today: > > http://rdiff-backup.org/ > >> For my own backup. Should I exclude my long name file from the backup >> for now? >> > > It's up to you, but I wouldn't worry about it. It should only be a > problem when a file with a really long name is created, modified, or > deleted, and then the next backup thereafter happens to have an > unrelated failure. I'm guessing such combinations are likely to be > rare. In such cases, you will need to "--check-destination-dir", as > usual, after the failure. If you then run another backup and it fails > with something like: > > ... > File "/usr/lib/python2.3/site-packages/rdiff_backup/increment.py", > line 123, in get_inc > assert not incrp.lstat(), incrp > AssertionError: Path: > dst/rdiff-backup-data/long_filename_data/1.2016-08-20T21:17:56-04:00.diff.gz > > > That's your clue that there are file(s) in > rdiff-backup-data/long_filename_data/ that are not being cleaned up. > Rerun "--check-destination-dir", then (assuming that was successful, > meaning you now have just 1 current_mirror file) look in the > rdiff-backup-data/long_filename_data/ directory and move out of the way > any files with a date/time in their names that matches the date/time in > the current_mirror filename. There might be numerous files, or there > might be just one, in which case the error message is telling you > exactly which one it is. > _______________________________________________ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
