Re: [rdiff-backup-users] Exception ... assert not incrp.lstat()

[Michael Born]

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.
>