[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joe Steele
Subject: Re: [rdiff-backup-users] Exception ... assert not incrp.lstat()
Date: Tue, 23 Aug 2016 15:29:24 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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
I now switched to the official Archiving repository and got the version
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.

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:


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:


But then there was an announcement that Sol1 was taking over official maintainership of rdiff-backup:


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:


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]