rdiff-backup-users
[Top][All Lists]
Advanced

[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: Mon, 22 Aug 2016 21:58:34 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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.



reply via email to

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