hurestore will always crash on startup (unfinished tool)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
HUBackup |
In Progress
|
Undecided
|
Sivan Greenberg | ||
hubackup (Ubuntu) |
Invalid
|
High
|
Sivan Greenberg |
Bug Description
Binary package hint: hubackup
The Home User Restore doesn't start:
ricardo@yuggoth:~ $ hurestore
Traceback (most recent call last):
File "/usr/bin/
main_restore = MainRestore(
File "/usr/lib/
MainBackup.
File "/usr/lib/
SimpleGlade
File "/usr/lib/
self.new()
File "/usr/lib/
self.
File "/usr/lib/
self.
AttributeError: MainRestore instance has no attribute 'prob_progress'
ricardo@yuggoth:~ $ dpkg -s hubackup | grep Version
Version: 0.0.4
Sivan Greenberg (sivan) wrote : | #1 |
Changed in hubackup: | |
importance: | Undecided → High |
status: | Unconfirmed → Confirmed |
assignee: | nobody → sivan |
Sivan Greenberg (sivan) wrote : | #2 |
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.
Ben Andersen (ben72) wrote : | #3 |
The exact same problem is also seen in version 0.0.6 on Edgy.
Sivan Greenberg (sivan) wrote : | #4 |
this is know, thank you, and I'm working on it.
Vicente Ruiz (uve) wrote : | #5 |
- hurestore crash Edit (31.4 KiB, text/plain)
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/
main_restore = MainRestore(
File "/usr/lib/
MainBackup.
File "/usr/lib/
SimpleGlade
File "/usr/lib/
self.new()
File "/usr/lib/
self.
File "/usr/lib/
self.
AttributeError: MainRestore instance has no attribute 'prob_progress'
Apport say "hurestore crashed with AttributeError in updateDeviceLis
mafix (mafix) wrote : | #6 |
can also confirm the same error on feisty with version 0.0.7
Martin Bergner (martin-bergner) wrote : | #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.
Adam Petaccia (mighmos) wrote : | #8 |
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.
Martin Bergner (martin-bergner) wrote : | #9 |
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 ... .
Ricardo Fuentes (jirah) wrote : | #10 |
I can confirm the same error on feisty.
IMHO, is a great development, dude, just need a little part of Q&A :D
Felipe Figueiredo (philsf) wrote : | #11 |
Still happens on a gutsy fresh install.
Daeng Bo (daengbo) wrote : | #12 |
Gutsy error:
danielbo@
[sudo] password for danielbo:
Traceback (most recent call last):
File "/usr/bin/
main_restore = MainRestore(
File "/usr/lib/
MainBackup.
File "/usr/lib/
SimpleGlade
File "/usr/lib/
self.new()
File "/usr/lib/
self.
File "/usr/lib/
self.
AttributeError: MainRestore instance has no attribute 'prob_progress'
Daeng Bo (daengbo) wrote : | #13 |
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?
Daeng Bo (daengbo) wrote : | #14 |
This bug is a duplicate of Bug #60809
zeddock (zeddock) wrote : Re: [Bug 64594] Re: [Edgy] hurestore crashes on startup | #15 |
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:/
> You received this bug notification because you are a member of Ubuntu
> Backup Team, which is a bug contact for hubackup in ubuntu.
>
Martin Bergner (martin-bergner) wrote : Re: [Edgy] hurestore crashes on startup | #16 |
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
Changed in hubackup: | |
assignee: | nobody → sivan |
status: | New → In Progress |
Ricardo Fuentes (jirah) wrote : | #17 |
Why this package is in the distribution?
Clearly hurestore is not this finished.
Adam Petaccia (mighmos) wrote : | #18 |
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.
Jonathon Hodges (jonblondie) wrote : | #19 |
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.
tiggsy (frann-leach) wrote : | #20 |
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?
jel (jellevdwaa) wrote : | #21 |
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.
Martin Bergner (martin-bergner) wrote : | #22 |
Hello,
we ran into some problems when trying to do hurestore. There is information at http://
where Sivan explains how to do it by hand. For further information, hubackup uses dar (DiskARchiver) as its backend.
Felipe Figueiredo (philsf) wrote : | #23 |
Any hope this will be fixed for intrepid?
If that's the case, will a patch be backported to hardy?
Milan Bouchet-Valat (nalimilan) wrote : | #24 |
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...
John Toliver (john-toliver) wrote : Re: [Bug 64594] Re: hurestore will always crash on startup (unfinished tool) | #25 |
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:/
> You received this bug notification because you are a direct subscriber
> of the bug.
Martin Bergner (martin-bergner) wrote : | #26 |
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.
vince (bullet-ballmail) wrote : | #27 |
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
Adam Petaccia (mighmos) wrote : | #28 |
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.
tiggsy (frann-leach) wrote : | #29 |
Can someone tell me how to unsubscribe from this thread?
Rob Pearman (rob-pearman) wrote : | #30 |
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.
Donovan (donovan2014) wrote : | #31 |
I agree with Adam: this software is not working at all, it's really better to remove it very quickly.
tdflanders (thomasdelbeke) wrote : | #32 |
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.
tdflanders (thomasdelbeke) wrote : | #33 |
tdflanders (thomasdelbeke) wrote : | #34 |
tdflanders (thomasdelbeke) wrote : | #35 |
tdflanders (thomasdelbeke) wrote : | #36 |
- gdb-hurestore.txt Edit (455 bytes, text/plain)
Correction:
gdb was not successful at all due to lack in dbg and dbgsym.
Please see full comments on #320421.
root@thomas-
[...]
(gnome-
Traceback (most recent call last):
File "/usr/bin/
main_restore = MainRestore(
File "/usr/lib/
MainBackup.
File "/usr/lib/
SimpleGlade
File "/usr/lib/
self.new()
File "/usr/lib/
self.
File "/usr/lib/
self.
[...]
Felipe Figueiredo (philsf) wrote : Re: [Bug 64594] Re: hurestore will always crash on startup (unfinished tool) | #37 |
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.
Cliffm (c2mcatee) wrote : Re: [Bug 64594] Re: hurestore will always crash on startup (unfinished tool) | #38 |
Felipe
Try using this link. it worked for me.
http://
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.
>
tdflanders (thomasdelbeke) wrote : | #39 |
Hi there Felipe,
you are correct. I should have read the manual better. I missed the dar part.
root@thomas-
GNOME hurestore 0.0.1
root@thomas-
Usage: hurestore [OPTION...]
-
Help options
-?, --help Show this help message
--usage Display brief usage message
Bonobo activation Support
-
-
--oaf-private Prevent registering of server
GNOME Library
-
-
-
--version 2.24.1
root@thomas-
^Z
root@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-
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-
/home/thomas/
Continuing...
/home/thomas/
Continuing...
/home/thomas/
[3]+ Stopped dar -x /home/thomas/
root@thomas-
/home/thomas/
tdflanders (thomasdelbeke) wrote : | #40 |
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 ...
tdflanders (thomasdelbeke) wrote : | #41 |
Ok,
I have all my data back. No luck with gdb.
root@thomas-
Invalid MIT-MAGIC-COOKIE-1 key/var/
warnings.
Usage: hurestore [-?] [-?|--help] [--usage] [--oaf-ior-fd=FD]
root@thomas-
Milan Bouchet-Valat (nalimilan) wrote : | #42 |
I filed bug 320797, we really need to take care of this...
Felipe Figueiredo (philsf) wrote : | #43 |
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
Martin Bergner (martin-bergner) wrote : | #44 |
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...
Felipe Figueiredo (philsf) wrote : | #45 |
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.
Phillip Susi (psusi) wrote : | #46 |
The hubackup package has been removed and is no longer supported. Closing all related bugs.
Changed in hubackup (Ubuntu): | |
status: | Confirmed → Invalid |
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.