restore crashes when the destination path or file is non existent

Bug #383383 reported by gt
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
sbackup
Fix Released
Undecided
Unassigned

Bug Description

Created a backup in 8.10. Restoring /etc/ in 9.04.
On restoring the backup (using the gui), started in terminal the operation hangs with the following message:

etc/alternatives/midbrowser-flashplugin
Traceback (most recent call last):
  File "/usr/sbin/simple-restore-gnome", line 413, in restore
    self._do_restore( self.src, self.src )
  File "/usr/sbin/simple-restore-gnome", line 406, in _do_restore
    r.restore( tdir, src, dst )
  File "/usr/share/sbackup/srestore.py", line 97, in restore
    if os.path.exists(dst) and not filecmp.cmp(src, dst):
  File "/usr/lib/python2.6/filecmp.py", line 42, in cmp
    s1 = _sig(os.stat(f1))
OSError: [Errno 2] No such file or directory: '/etc/tmpL1ejVH/etc/alternatives/midbrowser-flashplugin'

/etc/tmp*/etc/alternatives/ folder did not exist when it tried to do the 'if path exists and not filecmp'
nor did any files in it.
manually creating the alternatives folder AND touching the file /etc/tmp*/etc/alternatives/midbrowser-flashplugin skipped the error on this file.
(i used a shell script to create the folder after the tmp* dir was created and touch the files - before the restore hit the file but the error happens again when it hits fonts.)
Some files are restored (to the /etc/tmp*/etc/) before it hits the alternatives dir so i don't know why it stops here.

etc/fonts/conf.d/50-user.conf
etc/fonts/conf.d/30-metric-aliases.conf
Traceback (most recent call last):
  File "/usr/sbin/simple-restore-gnome", line 413, in restore
    self._do_restore( self.src, self.src )
  File "/usr/sbin/simple-restore-gnome", line 406, in _do_restore
    r.restore( tdir, src, dst )
  File "/usr/share/sbackup/srestore.py", line 97, in restore
    if os.path.exists(dst) and not filecmp.cmp(src, dst):
  File "/usr/lib/python2.6/filecmp.py", line 42, in cmp
    s1 = _sig(os.stat(f1))
OSError: [Errno 2] No such file or directory: '/etc/tmpUztj9u/etc/fonts/conf.d/30-metric-aliases.conf'

-it can't compare what doesn't yet exist? -
I'm too dumb to fix it (without some help ;) ).

Please help! I need to restore this backup!!

Revision history for this message
AndrewJones (andrew-jones11235) wrote :

I am having a similar problem.
Using latest version from Fedora 11
Jul 09 14:50:50 Installed: sbackup-0.10.5-7.fc11.noarch

Backup was created with unknown version under Fedora 10

Running from a terminal window I get this

[root@d400 jonesap]# simple-restore-gnome
/usr/sbin/simple-restore-gnome:395: GtkWarning: gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed
  response = dialog.run()
var/www/html/azurita
Traceback (most recent call last):
  File "/usr/sbin/simple-restore-gnome", line 413, in restore
    self._do_restore( self.src, self.src )
  File "/usr/sbin/simple-restore-gnome", line 406, in _do_restore
    r.restore( tdir, src, dst )
  File "/usr/share/sbackup/srestore.py", line 97, in restore
    if os.path.exists(dst) and not filecmp.cmp(src, dst):
  File "/usr/lib/python2.6/filecmp.py", line 42, in cmp
    s1 = _sig(os.stat(f1))
OSError: [Errno 2] No such file or directory: '/var/www/html/azurita/tmpAT83jg/var/www/html/azurita/'

=============================================
This line...

/usr/sbin/simple-restore-gnome:395: GtkWarning: gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed

...happens immediately and is a gtk2 bug which should be fixed at the next release:
http://bugzilla.gnome.org/show_bug.cgi?id=580511
 =============================================

The rest happens after an hour as the files I want are at the end of 22GB tgz file on a linux based NAS running Samba.

It looks to me like there is a problem concatenating paths.

I am trying to restore the directory structure /var/www/html/azurita/

(After an earlier, similar failure I created the azurita directory with correct permissions to see if that helped)

The restore program immediately created a directory /var/www/html/azurita/tmpAT83jg

As you can see the error appears to show a concatenation of this temporary path with the path I really want.
/var/www/html/azurita/tmpAT83jg/var/www/html/azurita/

On my first attempt the azurita directory did not exist and the error that time showed a similar concatenation:
/var/www/html/tmpgskeE2/ var/www/html/azurita/ (From memory but I'm pretty sure that's correct)

Oh yes; There is no indication on the GUI that it has failed. It still displays the "This may take some time" message. But there is no more network activity and system-restore only appears on the 'top' display for a moment when I click on the GUI and it regains focus.

Revision history for this message
AndrewJones (andrew-jones11235) wrote :

Further information.

The strange concatenation of paths I mentioned above _MAY_ be the result of an earlier failure - namely that all my full backups appear to be incomplete. I guess I should have re-opened this bug

https://bugs.launchpad.net/sbackup/+bug/111825

I will do so when I have completed this comment.

I'm not sure if I have the syntax right but this looks like it was doing what I expected it to:

[monitors@c600 ~]$ time gunzip -c /mnt/erised/jonesap/Backups/D400/2009-06-27_00.27.03.950336.d400.hogwarts.local.ful/files.tgz | tar -xvf - /var/www/html/azurita

gzip: /mnt/erised/jonesap/Backups/D400/2009-06-27_00.27.03.950336.d400.hogwarts.local.ful/files.tgz: invalid compressed data--format violated
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

real 73m4.239s
user 8m32.722s
sys 4m36.634s

Revision history for this message
AllesMeins (spam-startrekarchiv) wrote :

Add me to the list of those seeking help... I've the same problems with a backup of /etc that is useless because simple backup is not able to restore it.

Changed in sbackup:
status: New → Fix Committed
Changed in sbackup:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.