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

[Joe Steele]

On 8/22/2016 4:21 PM, Michael Born wrote:
> Wow, that was a fast response.
>
>
>
> Am 21.08.2016 um 04:37 schrieb Joe Steele:
> > This is a bug.  I was able to reproduce it and have created an issue for
> > it here:
> >
> > https://github.com/sol1/rdiff-backup/issues/9
> >
> > You can try to work around your problem by:
> >
> > 1) using '--check-destination-dir'; then
> That one failed 'Too many recent increments'
> ( http://pastebin.com/vXnmrMug )

'Too many recent increments' -- that shouldn't happen.  I know of a way 
to reproduce such an error, but it involves indiscriminate juggling of 
current_mirror files (that's a little foreshadowing).

> > 2) look at the name of your current_mirror file (and there must only be
> > one of them).  In your case, it looks like that name would be:
> >
> > /run/media/miborn/WD1TB/T450s_rdiff-backup/rdiff-backup-data/current_mirror.2016-07-21T22:41:21+02:00.data
>
> After removing current_mirror.2016-08-21T22:07:29+02:00.data I can again
> --list-increments
> ( *this output is from todays try* http://pastebin.com/V0bKu3LV )

Hold on.  It is never appropriate to remove current_mirror files 
manually.  Maybe I wasn't being clear about "there must only be one of 
them".  I certainly didn't mean for you to manually remove any 
current_mirror files.

Normally there is only one current_mirror file.  But when rdiff-backup 
starts, it creates a new current_mirror file and leaves the old file in 
place.  If the backup completes successfully, then the old file is 
removed.  But if there is an error, rdiff-backup quits, leaving you with 
2 current_mirror files.  Subsequent runs of rdiff-backup will then 
complain that the last backup failed and that you should use 
"--check-destination-dir" to fix the problem.  Running "rdiff-backup 
--check-destination-dir" cleans up the repository after the last failed 
backup and then removes the second (i.e., more recent) current_mirror 
file so there is only one current_mirror file again. That process is the 
*only* way that should be used to remove a second current_mirror file.

Regarding your log immediately above -- It shows:

|     increments.2016-07-21T22:41:21+02:00.dir   Thu Jul 21 22:41:21 2016
| Current mirror: Thu Jul 21 22:41:21 2016

That is showing that your last increment has the same date/time 
(2016-07-21T22:41:21) as your current_mirror file.  That's messed up. 
The current mirror should be later than the last increment.  But I guess 
that makes sense, knowing that you deleted a second current mirror file 
with a later date.

> > 3) look in 'rdiff-backup-data/long_filename_data/' and remove (but keep
> > somewhere safe, just in case) any files there that have a date in their
> > filename that is greater or equal to the date in the current_mirror
> > filename.  In your case, it looks like there will at least be:
> >
> > /run/media/miborn/WD1TB/T450s_rdiff-backup/rdiff-backup-data/long_filename_data/1.2016-07-30T16:25:41+02:00.diff.gz
> I did remove that file yesterday but it didn't fix the problem.
> Running my backup gave me immediately this error:
> http://pastebin.com/qLtRe861
>
> I tried the steps 1-3 again today. This time there was no
> 1.2016-07-30T16:25:41+02:00.diff.gz file to remove in long_filename_data/
> But a new current_mirror.2016-08-21T22:07:29+02:00.data file had to be
> removed.

No!  Don't remove current_mirror files!

> The result was the same. I could run the --list-increments option
> successfully, but the backup failed with the exception.
>
> Do you have more suggestions what I could try?
>
> Thank you.
> Michael
>
> > That *should* fix things for you, but I give no guarantees.
> >
> > I am a little puzzled about why the date of the file in the
> > long_filename_data/ directory is greater than (instead of equal to) the
> > date of your current_mirror (after having regressed the repository).  I
> > guess that would be possible if you regressed your repository backward
> > more than just a single increment.
> >
> >
> > On 8/20/2016 7:13 AM, Michael Born wrote:
> > > Dear rdiff-backup users.

<snip>

> > > 3. I used the option --exclude
> > > /home/miborn/.kde4/share/apps/okular/docdata/ to exclude the file where
> > > the Exception happened before. Unfortunately rdiff-backup presented me a
> > > new error message:
> > > File "/usr/lib64/python2.7/gzip.py", line 432, in seek
> > >     raise IOError('Negative seek in write mode')
> > > (longer message see here: http://pastebin.com/G64SrnVn )

Unfortunately, I didn't read your first message carefully enough to 
notice the above error until now.  It seems you are using a buggy 
version of rdiff-backup created by openSUSE.  The line numbers in the 
above log indicates that your version of rdiff-backup was patched with 
this unofficial patch:

https://build.opensuse.org/package/view_file/openSUSE:Factory/rdiff-backup/rdiff-backup-1.2.8-sparsefiles.diff?expand=1

But you do not have this patch which fixes a bug in the above patch:

https://build.opensuse.org/package/view_file/openSUSE:Factory/rdiff-backup/rdiff-backup-1.2.8-sparse-no-seek-in-gzip.diff?expand=1

I don't know much about openSUSE, but this rpm seems to have both patches:

http://download.opensuse.org/repositories/Archiving/openSUSE_13.2/x86_64/rdiff-backup-1.2.8-42.5.x86_64.rpm

It's likely that your problems may have all started with a "Negative 
seek in write mode" error (similar to that contained in your log above, 
and fixed by the second patch above).  That error caused rdiff-backup to 
fail.  You then were unfortunate enough to encounter another bug 
(https://github.com/sol1/rdiff-backup/issues/9) that prevented 
"--check-destination-dir" from working because your backup contained 
file(s) with unusually long names.

The first thing to do would be to get a version of rdiff-backup from 
openSUSE that is fully patched.

Next -- well, I'm not sure what's next.  You have attempted backups, 
used an rdiff-backup-regress script, removed current_mirror files, and 
attempted more backups.  Sorting that out might be tricky.  A listing of 
the files & folders contained in your rdiff-backup-data/ directory might 
help as a first step to see what the different dates in the filenames show.