hurestore will always crash on startup (unfinished tool)

If this happens on Edgy, then it's known. I'm currently working to finish the restoration support, as it's still not there and this crash is due to code trying to find non existent widgets references from the old GUI.

correction, to finish the gui on top of the already existing restoratoin process, in my previous comment it sounds as if it needs to be re-implemented.

The exact same problem is also seen in version 0.0.6 on Edgy.

this is know, thank you, and I'm working on it.

I have same error on Feisty with 0.0.7 version.

vruiz@SamsungX05:~$ hurestore
GTK Accessibility Module initialized
Traceback (most recent call last):
  File "/usr/bin/hurestore", line 37, in <module>
    main_restore = MainRestore(path=glade_dir + "/hurestore.glade")
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hurestore.py", line 50, in __init__
    MainBackup.__init__(self, path,root,domain, **kwargs)
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hubackup.py", line 58, in __init__
    SimpleGladeApp.__init__(self, path, root, domain, **kwargs)
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/SimpleGladeApp.py", line 108, in __init__
    self.new()
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hurestore.py", line 63, in new
    self.updateDeviceLists()
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hurestore.py", line 70, in updateDeviceLists
    self.prob_progress.set_fraction(0.5)
AttributeError: MainRestore instance has no attribute 'prob_progress'

Apport say "hurestore crashed with AttributeError in updateDeviceLists()"

can also confirm the same error on feisty with version 0.0.7

thanks for your comments, but we need to pave the work for further development first, so right now, it will still take some time until hurestore will work as expected, sorry.

I almost posted a bug report until I came across this. Having a backup program that backs up but doesn't restore is slightly annoying.

Yes, I know, but we are working on it. You can use dar right now to process the files, but we made some good progress so this will hopefully work at some point in the near future ... .

I can confirm the same error on feisty.

IMHO, is a great development, dude, just need a little part of Q&A :D

Still happens on a gutsy fresh install.

Gutsy error:
danielbo@danielbo-desktop:~$ sudo hurestore
[sudo] password for danielbo:
Traceback (most recent call last):
  File "/usr/bin/hurestore", line 37, in <module>
    main_restore = MainRestore(path=glade_dir + "/hurestore.glade")
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hurestore.py", line 50, in __init__
    MainBackup.__init__(self, path,root,domain, **kwargs)
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hubackup.py", line 58, in __init__
    SimpleGladeApp.__init__(self, path, root, domain, **kwargs)
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/SimpleGladeApp.py", line 108, in __init__
    self.new()
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hurestore.py", line 63, in new
    self.updateDeviceLists()
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hurestore.py", line 70, in updateDeviceLists
    self.prob_progress.set_fraction(0.5)
AttributeError: MainRestore instance has no attribute 'prob_progress'

If this package just doesn't work and hasn't worked for 14 months, shouldn't it be dropped from the repositories? What's the reason for keeping it?

"Sivan Greenberg wrote on 2006-10-22: (permalink)
this is know, thank you, and I'm working on it."

Apparently Sivian dropped off the face of the Earth. Anyway, he's not working on it, so can it be reassigned?

This bug is a duplicate of Bug #60809

It does seem to be stalled.
zeddock

On Dec 27, 2007 10:53 AM, Daeng Bo <email address hidden> wrote:
> This bug is a duplicate of Bug #60809
>
>
> --
> [Edgy] hurestore crashes on startup
> https://bugs.launchpad.net/bugs/64594
> You received this bug notification because you are a member of Ubuntu
> Backup Team, which is a bug contact for hubackup in ubuntu.
>

Well neither Sivan nor me dropped off the earth (the gravity is quite strong), but there are sometimes other things that can keep you busy, especially when you program in your free time. Sivan is at the moment (or was) working on something in this direction, but the problem is not that easy to solve. This is also the reason why there doesn't seem to be too much progress

Why this package is in the distribution?

Clearly hurestore is not this finished.

I agree that hurestore should probably be dropped until it is in a working state. Unfortunately, Hardy just got released, so it probably wont be dropped from 8.04.

I'll keep my eye out for this being fixed then, I'm pleased how simple the hubackup tool is, so I'm hopeful that the restore tool will be just as good. Keep up the good work guys.

This is not good. I was hoping to restore my backup.

I'm on hardy, so i am surprised that this package has not yet been fixed. it seems to have been a known problem for some time.

In the meantime, how does one restore from a backup created with hubackup?

Well if it's a .tar or .tar.gz or another compressed file, you can use file-roller. I advice you to work with Sbackup or timevualt this backupprograms have a better development.

Hello,

we ran into some problems when trying to do hurestore. There is information at http://sivang.blogspot.com/2008/01/restoring-file-using-hubackup.html
where Sivan explains how to do it by hand. For further information, hubackup uses dar (DiskARchiver) as its backend.

Any hope this will be fixed for intrepid?

If that's the case, will a patch be backported to hardy?

This bug is still not fixed. Hurestore is not a finished program, and would better be removed from the repositories. Don't hope you'll get it for Intrepid...

I agree. Between sbackup which "appears" to be working correctly, and
hubackup/restore which doesn't work at all, I'm just about ready to
start scripting my own backup scheme which I don't want to do, but I
agree, hu* shouldn't even be mentioned and should be removed from the
repos until it does work, and on the off chance that it actually has
been fixed, it should be put on the queue to upgrade.

On Thu, Aug 28, 2008 at 14:03, Milan <email address hidden> wrote:
> This bug is still not fixed. Hurestore is not a finished program, and
> would better be removed from the repositories. Don't hope you'll get it
> for Intrepid...
>
> --
> hurestore will always crash on startup (unfinished tool)
> https://bugs.launchpad.net/bugs/64594
> You received this bug notification because you are a direct subscriber
> of the bug.

It was a bad decision to promote hubackup (which works in most cases) and hurestore as a main backup tool since they are not finished. I tried to help Sivan getting hurestore to work, but didn't succed.

Maybe someone else has a better idea, so I will create some background information for someone to start.

The problem with hurestore is, that you need to create an interface to dar.

I tried the dar python bindings, but they are unstable and also unfinished. I have a bzr branch on lp for both the bindings (dar-python) and hurestore (look in my branches) which uses these bindings and can show the contents of the archive. The problem is however, that there you cannot have any statistics about the archive (the bindings fail there and I didn't get them to work) and that is needed at some point.

I also tried to interface dar directly, but is this error-prone and quite slow. The usage of appropriate bindings would be much better.

I am willing to help anyone starting on that, but you should have some (or better good) knowledge on python, pygtk, python bindings, swig, c++ and (at the end) building debian packages. I think that these are a lot of requirements for such a small tool. Of course, the swig and binding part is optional, but preferred. Dar is written in C++, so is the library. If you want to use (fix) the bindings you need to know that as well.

Contact me if you like to help.

Martin Bergner wrote:
> It was a bad decision to promote hubackup (which works in most cases)
> and hurestore as a main backup tool since they are not finished. I tried
> to help Sivan getting hurestore to work, but didn't succed.
>
> Maybe someone else has a better idea, so I will create some background
> information for someone to start.
>
> The problem with hurestore is, that you need to create an interface to
> dar.
>
> I tried the dar python bindings, but they are unstable and also
> unfinished. I have a bzr branch on lp for both the bindings (dar-python)
> and hurestore (look in my branches) which uses these bindings and can
> show the contents of the archive. The problem is however, that there you
> cannot have any statistics about the archive (the bindings fail there
> and I didn't get them to work) and that is needed at some point.
>
> I also tried to interface dar directly, but is this error-prone and
> quite slow. The usage of appropriate bindings would be much better.
>
> I am willing to help anyone starting on that, but you should have some
> (or better good) knowledge on python, pygtk, python bindings, swig, c++
> and (at the end) building debian packages. I think that these are a lot
> of requirements for such a small tool. Of course, the swig and binding
> part is optional, but preferred. Dar is written in C++, so is the
> library. If you want to use (fix) the bindings you need to know that as
> well.
>
> Contact me if you like to help.
>
>
Martin, I would like to help but unfortunately my programming knowledge
is non-existent. With regard to the above problem, I've run from the
fight & am hiding behind "sbackup" which seems to work just fine.Good
luck with sorting out "hurestore".
Vincent

Can this please be removed from the repos? The software is NON FUNCTIONING and MISLEADING. While the user may be able to drop to the CLI and use dar, tar or whatever, this is what the software is supposed to do, and doesn't. When the hurestore actually works, it can be reincluded.

This is the same as if brasero were only able to create ISO files and then telling the user to use cdrecord to burn them, or if firefox told the user to wget the webpages before viewing them.

Can someone tell me how to unsubscribe from this thread?

Adam - There's a link on the right-hand side of the bug page (under 'duplicates') that you can use to unsubscribe.

Tiggsy - I agree the fact the restore is completely non functional is frustrating. I still use it for backups however but use DAR directly to do any restores I need.

I agree with Adam: this software is not working at all, it's really better to remove it very quickly.

I marked mine as a duplicate (320421), please change importance to critical and fix or remove this package ASAP. I have significant data loss. Is there anyway to retrieve data from it? It did the validation in hubackup and it was marked as valid, so I reformatted. This is a huge problem because I lost legal documents. I seems to be a segfaulting condition. Uploading valgrind, strace and gdb log. gdb is only partially successful.

Correction:

gdb was not successful at all due to lack in dbg and dbgsym.

Please see full comments on #320421.

root@thomas-laptop:/home/thomas# cat /home/thomas/.xsession-errors
[...]
(gnome-screenshot:12920): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated
Traceback (most recent call last):
  File "/usr/bin/hurestore", line 37, in <module>
    main_restore = MainRestore(path=glade_dir + "/hurestore.glade")
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hurestore.py", line 50, in __init__
    MainBackup.__init__(self, path,root,domain, **kwargs)
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hubackup.py", line 58, in __init__
    SimpleGladeApp.__init__(self, path, root, domain, **kwargs)
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/SimpleGladeApp.py", line 108, in __init__
    self.new()
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hurestore.py", line 63, in new
    self.updateDeviceLists()
  File "/usr/lib/python2.5/site-packages/HUBackup/GUI/hurestore.py", line 70, in updateDeviceLists
    self.prob_progress.set_fraction(0.5)
[...]

On Fri, Jan 23, 2009 at 5:55 PM, tdflanders <email address hidden> wrote:
> I marked mine as a duplicate (320421), please change importance to
> critical and fix or remove this package ASAP. I have significant data
> loss. Is there anyway to retrieve data from it? It did the validation in
> hubackup and it was marked as valid, so I reformatted. This is a huge
> problem because I lost legal documents. I seems to be a segfaulting
> condition. Uploading valgrind, strace and gdb log. gdb is only partially
> successful.
>

What do you mean by data loss? This bug is about the GUI not working,
but the backup itself should be fine. If your backup is corrupted in
anyway, you have another bug.

You must use the command line for dar to recover your backup. It's
described in the program's site and elsewhere. There are plenty
tutorials around on how to use dar via command line.

Felipe
Try using this link. it worked for me.
http://dar.linux.free.fr/doc/index.html
and download dar gui
The hu should be deleted from Ubuntu and Linux.

On Fri, 2009-01-23 at 21:47 +0000, Felipe Figueiredo wrote:

> On Fri, Jan 23, 2009 at 5:55 PM, tdflanders <email address hidden> wrote:
> > I marked mine as a duplicate (320421), please change importance to
> > critical and fix or remove this package ASAP. I have significant data
> > loss. Is there anyway to retrieve data from it? It did the validation in
> > hubackup and it was marked as valid, so I reformatted. This is a huge
> > problem because I lost legal documents. I seems to be a segfaulting
> > condition. Uploading valgrind, strace and gdb log. gdb is only partially
> > successful.
> >
>
> What do you mean by data loss? This bug is about the GUI not working,
> but the backup itself should be fine. If your backup is corrupted in
> anyway, you have another bug.
>
> You must use the command line for dar to recover your backup. It's
> described in the program's site and elsewhere. There are plenty
> tutorials around on how to use dar via command line.
>

Hi there Felipe,

you are correct. I should have read the manual better. I missed the dar part.
root@thomas-laptop:/home/thomas# hurestore --version
GNOME hurestore 0.0.1
root@thomas-laptop:/home/thomas# hurestore --help
Usage: hurestore [OPTION...]
      --load-modules=MODULE1,MODULE2,... Dynamic modules to load

Help options
  -?, --help Show this help message
      --usage Display brief usage message

Bonobo activation Support
      --oaf-ior-fd=FD File descriptor to print IOR on
      --oaf-activate-iid=IID IID to activate
      --oaf-private Prevent registering of server
                                             with OAF

GNOME Library
      --disable-sound Disable sound server usage
      --enable-sound Enable sound server usage
      --espeaker=HOSTNAME:PORT Host:port on which the sound
                                             server to use is running
      --version 2.24.1
root@thomas-laptop:/home/thomas# man hurestore
^Z

root@thomas-laptop:/home/thomas#

Cliffm, thanks a lot for the manual, but this stuff does not work either. The command hangs. Maybe it is the cause of the segmentation fault in the gui. As I know have the debug sym's (for dar) I will do the Backtrace again, in case people want to repair it still. First let's get my data back.

root@thomas-laptop:/home/thomas# dar -V

 dar version 2.3.8, Copyright (C) 2002-2052 Denis Corbin
   Long options support : YES

 Using libdar 4.4.3 built with compilation time options:
   Libz compression (gzip) : YES
   Libbz2 compression (bzip2) : YES
   Strong encryption : YES
   New Blowfish implementation: YES
   Extended Attributes support: YES
   Large files support (> 2GB): YES
   ext2fs NODUMP flag support : YES
   Special allocation scheme : YES
   Integer size used : 64 bits
   Thread safe support : YES

 compiled the Jul 2 2008 with GNUC version 4.3.1
 dar is part of the Disk ARchive suite (Release 2.3.8)
 dar comes with ABSOLUTELY NO WARRANTY; for details
 type `dar -W'. This is free software, and you are welcome
 to redistribute it under certain conditions; type `dar -L | more'
 for details.

root@thomas-laptop:/home/thomas# dar -x /home/thomas/Desktop/thomas-master-archive.1.da
/home/thomas/Desktop/thomas-master-archive.1.da.1.dar is required for further operation, please provide the file. [return = OK | Esc = cancel]
Continuing...
/home/thomas/Desktop/thomas-master-archive.1.da.1.dar is required for further operation, please provide the file. [return = OK | Esc = cancel]
Continuing...
/home/thomas/Desktop/thomas-master-archive.1.da.1.dar is required for further operation, please provide the file. [return = OK | Esc = cancel]

[3]+ Stopped dar -x /home/thomas/Desktop/thomas-master-archive.1.da
root@thomas-laptop:/home/thomas# dar -x /home/thomas/Desktop/thomas-master-archive.1.da
/home/thomas/Desktop/thomas-master-archive.1.da.1.dar is required for further operation, please provide the file. [return...

STUPID

I mistyped obviously ...

Had too many Belgian beers I guess. Sorry for wasting your time with that.

Anyway, it is running now. I'll do the gdb of hurestore now.

Ok it's finished, but the Desktop did not restore.

let's see after reboot ...

Ok,

I have all my data back. No luck with gdb.

root@thomas-laptop:/home/thomas# hurestore --usage
Invalid MIT-MAGIC-COOKIE-1 key/var/lib/python-support/python2.5/gtk-2.0/gtk/__init__.py:72: GtkWarning: could not open display
  warnings.warn(str(e), _gtk.Warning)
Usage: hurestore [-?] [-?|--help] [--usage] [--oaf-ior-fd=FD]
        [--oaf-activate-iid=IID] [--oaf-private] [--disable-sound]
        [--enable-sound] [--espeaker=HOSTNAME:PORT] [--version]
        [--load-modules=MODULE1,MODULE2,...]
root@thomas-laptop:/home/thomas#

I filed bug 320797, we really need to take care of this...

Martin Bergner escreveu:
> It was a bad decision to promote hubackup (which works in most cases)
> and hurestore as a main backup tool since they are not finished. I tried
> to help Sivan getting hurestore to work, but didn't succed.
>
Martin,

do you agree it would be best to develop hubackup off the distribution,
and re-include it in the archive when it's ready? Without further
frustrating users

do you think maybe it would be best to develop hubackup off the
distribution, and re-include it in the archive when it's ready?

> Maybe someone else has a better idea, so I will create some background
> information for someone to start.
>
> The problem with hurestore is, that you need to create an interface to
> dar.
>
> I tried the dar python bindings, but they are unstable and also
> unfinished. I have a bzr branch on lp for both the bindings (dar-python)
> and hurestore (look in my branches) which uses these bindings and can
> show the contents of the archive. The problem is however, that there you
> cannot have any statistics about the archive (the bindings fail there
> and I didn't get them to work) and that is needed at some point.
>
This doesn't explain why the restore GUI refuses to start. Why does it
happen?

> I also tried to interface dar directly, but is this error-prone and
> quite slow. The usage of appropriate bindings would be much better.
>
> I am willing to help anyone starting on that, but you should have some
> (or better good) knowledge on python, pygtk, python bindings, swig, c++
> and (at the end) building debian packages. I think that these are a lot
> of requirements for such a small tool. Of course, the swig and binding
> part is optional, but preferred. Dar is written in C++, so is the
> library. If you want to use (fix) the bindings you need to know that as
> well.
>
> Contact me if you like to help.
>
It seems dealing with dar itself is a compromise of time, and
availability of a proper binding. I have some Perl skills, and have seen
Python, maybe I can help with that if there's some prototype somewhere
to give a headstart. If the GUI (pygtk) was at least working, it could
be a fast thing (not for Jaunty anymore).

Anyway, IMHO it should be removed from the archives until it's finished.

regards
FF

Hi Felipe,
> do you think maybe it would be best to develop hubackup off the
> distribution, and re-include it in the archive when it's ready?
Hubackup was removed from jaunty, see bug #320797 . So that is already
done.

> This doesn't explain why the restore GUI refuses to start. Why does it
> happen?
The GUI is simply not finished and can actually not run at all. It lacks
the code to actually do something.

> It seems dealing with dar itself is a compromise of time, and
> availability of a proper binding. I have some Perl skills, and have seen
> Python, maybe I can help with that if there's some prototype somewhere
> to give a headstart. If the GUI (pygtk) was at least working, it could
> be a fast thing (not for Jaunty anymore).
The problem is basically, that developing python bindings is not really
a big problem, once you know how to do it and have the time. Dar itself
(and libdar) is well written and contains a lot of C++ classes which
should be directly available in python. This means, that the classes and
methods should be wrapped to appropriate python classes. The usage of
these classes together with pygtk shouldn't be too difficult, given that
I had done it partly myself. However, the C++ code of Dar is using
nearly everything that makes classes in C++ fun, like friends,
overloading operators and templates. To make things worse, the templates
are then exchanged on a compile-time (pre-processor) case which makes
the whole thing not easier. Again, its not difficult, just time
consuming, if done right.

For reference, since python bindings can be done mostly on an automated
basis (if the code is not too complicated), someone used swig to do
exactly that. However, the usage of friends, overloaded operators and
compile-time settings force you to also dive deeply into swig to fix
those bindings. I think that a complete C++ rewrite of the bindings
would probably be easier than to fix the (now probably) completely
broken bindings.

For a start, I suggest you take a look at the libdar API itself and the
use cases on the wiki for hubackup. One can see that the ability to use
the bindings would make the integration not too difficult.
I have some code which you may want to see. There is a little more to
see than in the current code. You can browse through my branches if you
like, it should be in there. I don't have much time at the moment, but I
can look through the code in ~1 week. If you want to wait, I can then
point you directly to the interesting parts. Given that I haven't looked
at the code in a year or so, I need some preparation, though :).

It is possible to create a expect like interface to dar on the
commandline, but I suspect it to be quite slow. It doesn't provide some
useful information in order to make the display of data easy.

For the graphical interface, there is the glade stuff to define the
windows, but you need to do some work on e.g. displaying the data in a
treeview, providing progressbars and such. I have made some progress on
this in my code as well.

I hope I could shed some light on the issues around the problem. If you
need other specific information that I have not covered, don't hesitate
to contact me.

Regards...

Martin,

thanks, but no thanks. There are other backup software around, and if this one was already removed, this bug should be closed as WONTFIX, AIUI. I don't have the permission for that, though.

The hubackup package has been removed and is no longer supported. Closing all related bugs.