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: Michael Born
Subject: Re: [rdiff-backup-users] Exception ... assert not incrp.lstat()
Date: Tue, 23 Aug 2016 13:12:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

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 (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'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)

For my own backup. Should I exclude my long name file from the backup
for now?

Thank you.
Michael

Am 23.08.2016 um 03:58 schrieb 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.
> 




reply via email to

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