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

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