Welcome! » Log In » Create A New Profile

[bug] AssertionError: Bad index order

Posted by Ilario 
Ilario
[bug] AssertionError: Bad index order
May 28, 2017 04:50PM
Hi all!
I'm using rdiff-backup on Debian testing i386.
Copying from local (directory on encfs) and pasting on ssh remote (via
ssh tunnel done with ssh -L and localhost port set in .ssh/config,
remote is on ecryptfs).
The previous backup was interrupted because of an encfs segfault [1].
Now launching again the rdiff-backup command I get:

rdiff-backup --exclude .wine --exclude .cache .
ilario@localhost::ilario-laptop-rdiff-backup

Enter passphrase for key '/home/ilario/.ssh/id_rsa':
Previous backup seems to have failed, regressing destination now.
Exception 'Bad index order: ('long_filename_data', '820') >=
('backup-20140716', 'progetti', 'GeBuRi', '20121101-Progetto GeBuRi',
'articoli', 'calcoli')' raised of class '<type
'exceptions.AssertionError'>':
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
304, in error_check_Main
try: Main(arglist)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
324, in Main
take_action(rps)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
280, in take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
337, in Backup
backup_final_init(rpout)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
501, in backup_final_init
checkdest_if_necessary(rpout)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
920, in checkdest_if_necessary
dest_rp.conn.regress.Regress(dest_rp)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py",
line 450, in __call__
return apply(self.connection.reval, (self.name,) + args)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py",
line 370, in reval
if isinstance(result, Exception): raise result

Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 30, in <module>
rdiff_backup.Main.error_check_Main(sys.argv[1:])
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
304, in error_check_Main
try: Main(arglist)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
324, in Main
take_action(rps)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
280, in take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
337, in Backup
backup_final_init(rpout)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
501, in backup_final_init
checkdest_if_necessary(rpout)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line
920, in checkdest_if_necessary
dest_rp.conn.regress.Regress(dest_rp)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py",
line 450, in __call__
return apply(self.connection.reval, (self.name,) + args)
File "/usr/lib/python2.7/dist-packages/rdiff_backup/connection.py",
line 370, in reval
if isinstance(result, Exception): raise result
AssertionError: Bad index order: ('long_filename_data', '820') >=
('backup-20140716', 'progetti', 'GeBuRi', '20121101-Progetto GeBuRi',
'articoli', 'calcoli')
Fatal Error: Lost connection to the remote system

Should I file a bug report on github or on Debian?
Thanks!
Ilario

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849850

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
This message was imported via the External PhorumMail Module
Ilario
Re: [bug] AssertionError: Bad index order
May 28, 2017 04:50PM
2017-01-04 15:17 GMT+01:00 Ilario <iochesonome@gmail.com>:
> AssertionError: Bad index order: ('long_filename_data', '820') >=
> ('backup-20140716', 'progetti', 'GeBuRi', '20121101-Progetto GeBuRi',
> 'articoli', 'calcoli')

The fact that in that directory there's also a file with a long
filename could be a reason?
That file is named:
/home/ilario/backup-20140716/progetti/GeBuRi/20121101-Progetto
GeBuRi/articoli/calcoli/Design for geometric parameters of PEM fuel
cell by integrating computational fluid dynamics code with
optimization method.pdf

Some more information about the system:

Package: rdiff-backup
Version: 1.2.8-7

-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (980, 'testing'), (900, 'stable'), (200, 'unstable'),
(100, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.2.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rdiff-backup depends on:
ii libc6 2.24-8
ii librsync1 0.9.7-10
ii python 2.7.13-1
ii python2.7 2.7.13-1

Versions of packages rdiff-backup recommends:
ii python-pylibacl 0.5.3-1
ii python-pyxattr 0.5.6-1

Thanks,
Ilario

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
This message was imported via the External PhorumMail Module
Ilario
Re: [bug] AssertionError: Bad index order
May 28, 2017 04:50PM
2017-01-04 15:53 GMT+01:00 Ilario <iochesonome@gmail.com>:
> 2017-01-04 15:17 GMT+01:00 Ilario <iochesonome@gmail.com>:
>> AssertionError: Bad index order: ('long_filename_data', '820') >=
>> ('backup-20140716', 'progetti', 'GeBuRi', '20121101-Progetto GeBuRi',
>> 'articoli', 'calcoli')
>
> The fact that in that directory there's also a file with a long
> filename could be a reason?

On the remote side I found this message in backup.log file:

===
Previous backup seems to have failed, regressing destination now.
Warning: Could not restore file
backup-20140716/progetti/GeBuRi/20121101-Progetto GeBuRi/Progetto
GeBuRi.tar.gz!

A regular file was indicated by the metadata, but could not be
constructed from existing increments because last increment had type
None. Instead of the actual file's data, an empty length file will be
created. This error is probably caused by data loss in the
rdiff-backup destination directory, or a bug in rdiff-backup
Warning: Could not restore file
backup-20140716/progetti/GeBuRi/20121101-Progetto
GeBuRi/articoli/Effective transport properties for polymer electrolyte
membrane fuel cells.pdf!

A regular file was indicated by the metadata, but could not be
constructed from existing increments because last increment had type
None. Instead of the actual file's data, an empty length file will be
created. This error is probably caused by data loss in the
rdiff-backup destination directory, or a bug in rdiff-backup
Previous backup seems to have failed, regressing destination now.
===

It would not be a problem to remove entirely that directory from
remote and all its backup history from rdiff-backup as I still have
the original to copy over.
Is it possible?

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
This message was imported via the External PhorumMail Module
Dominic Raferd
Re: [bug] AssertionError: Bad index order
May 28, 2017 04:50PM
On 4 January 2017 at 16:08, Ilario <iochesonome@gmail.com> wrote:
> 2017-01-04 15:53 GMT+01:00 Ilario <iochesonome@gmail.com>:
>> 2017-01-04 15:17 GMT+01:00 Ilario <iochesonome@gmail.com>:
>>> AssertionError: Bad index order: ('long_filename_data', '820') >=
>>> ('backup-20140716', 'progetti', 'GeBuRi', '20121101-Progetto GeBuRi',
>>> 'articoli', 'calcoli')
>>
>> The fact that in that directory there's also a file with a long
>> filename could be a reason?
>
> On the remote side I found this message in backup.log file:
>
> ===
> Previous backup seems to have failed, regressing destination now.
> Warning: Could not restore file
> backup-20140716/progetti/GeBuRi/20121101-Progetto GeBuRi/Progetto
> GeBuRi.tar.gz!
>
> A regular file was indicated by the metadata, but could not be
> constructed from existing increments because last increment had type
> None. Instead of the actual file's data, an empty length file will be
> created. This error is probably caused by data loss in the
> rdiff-backup destination directory, or a bug in rdiff-backup
> Warning: Could not restore file
> backup-20140716/progetti/GeBuRi/20121101-Progetto
> GeBuRi/articoli/Effective transport properties for polymer electrolyte
> membrane fuel cells.pdf!
>
> A regular file was indicated by the metadata, but could not be
> constructed from existing increments because last increment had type
> None. Instead of the actual file's data, an empty length file will be
> created. This error is probably caused by data loss in the
> rdiff-backup destination directory, or a bug in rdiff-backup
> Previous backup seems to have failed, regressing destination now.
> ===
>
> It would not be a problem to remove entirely that directory from
> remote and all its backup history from rdiff-backup as I still have
> the original to copy over.
> Is it possible?

I'm not sure, but I think a better idea would be, since you still have
the original files (two are indicated in your message), to copy them
manually into the required directories of the rdiff-backup repository.
You might or might not have to alter some of the file's permissions
(depending how the original backup was done) - hopefully not. If this
is the only problem in the repository then this might enable the
regression to run. If it's possible it would be wise to take a backup
of your repository before trying this. Regressions are complex.

In principle I always verify my repositories before adding a new
backup and I maintain a secondary copy of all the repositories - on
another machine, so if things break (usually because of a disrupted
rdiff-backup session) I can fix them immediately and if the worst
happens and all regression attempts fail I should be able to go back
to the secondary repositories.

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
This message was imported via the External PhorumMail Module
Ilario
Re: [bug] AssertionError: Bad index order
May 28, 2017 04:50PM
2017-01-04 17:44 GMT+01:00 Dominic Raferd <dominic@timedicer.co.uk>:
> On 4 January 2017 at 16:08, Ilario <iochesonome@gmail.com> wrote:
>> 2017-01-04 15:53 GMT+01:00 Ilario <iochesonome@gmail.com>:
>>> 2017-01-04 15:17 GMT+01:00 Ilario <iochesonome@gmail.com>:
>>>> AssertionError: Bad index order: ('long_filename_data', '820') >=
>>>> ('backup-20140716', 'progetti', 'GeBuRi', '20121101-Progetto GeBuRi',
>>>> 'articoli', 'calcoli')
>>>
>>> The fact that in that directory there's also a file with a long
>>> filename could be a reason?
>>
>> It would not be a problem to remove entirely that directory from
>> remote and all its backup history from rdiff-backup as I still have
>> the original to copy over.
>> Is it possible?
>
> I'm not sure, but I think a better idea would be, since you still have
> the original files (two are indicated in your message), to copy them
> manually into the required directories of the rdiff-backup repository.
> You might or might not have to alter some of the file's permissions
> (depending how the original backup was done) - hopefully not. If this
> is the only problem in the repository then this might enable the
> regression to run. If it's possible it would be wise to take a backup
> of your repository before trying this. Regressions are complex.

Thanks for the suggestion!!!
But in a rush I deleted the whole corrupted dir on the remote side and
every entry referring to it in the mirror_metadata and
extended_attributes files.
The backup is still on going but it looks like the workaround did the job.

Do you think it's worth to dig into this bug?

> In principle I always verify my repositories before adding a new
> backup and I maintain a secondary copy of all the repositories - on
> another machine, so if things break (usually because of a disrupted
> rdiff-backup session) I can fix them immediately and if the worst
> happens and all regression attempts fail I should be able to go back
> to the secondary repositories.

Ok, sounds like a good practice! I will try :)
Thanks,
Ilario

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
This message was imported via the External PhorumMail Module
Sorry, only registered users may post in this forum.

Click here to login