Version 1.43.0 (in beta) fixes both of these, it's currently extras-development
if you wish to try it. Once it's been tested I will build for FC-5 and FC-6.

Can you take a look at bug #233799 as well and I'll test them both at the same time?

Sure - I added a comment to #233799, it should also be fixed in 1.43.0. In the
extras-development fwbackups will require to update to python2.5, which will
probably pull in half the development tree. If you need a FC6 rpm let me know. 

I would like the fc6 rpm if you could.

Here's a RPM for FC6 I build with Mock:
http://www.diffingo.com/downloads/fwbackups/fwbackups-1.43.0-0.1.beta2.fc6.noarch.rpm

I ran it from a terminal and got the first traceback, then it crashed in the
middle of defining a backup set:

[root@snowflake tmp]# fwbackups
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/fwbackups/guicallbacks.py", line 640,
in on_RestoreSetNameBox_changed
    self._populateDates(self.ui.RestoreSetNameBox.get_model().get_value(\
TypeError: iter must be a GtkTreeIter
*** glibc detected *** python: free(): invalid pointer: 0x09731ab8 ***
======= Backtrace: =========
/lib/libc.so.6[0x41109d]
/lib/libc.so.6(cfree+0x90)[0x4146f0]
/lib/libglib-2.0.so.0(g_free+0x31)[0x68d6e1]
/usr/lib/libgtk-x11-2.0.so.0[0x52e9fcc]
/lib/libgobject-2.0.so.0(g_object_unref+0x16c)[0x70e0dc]
/usr/lib/libgtk-x11-2.0.so.0[0x536bae7]
/usr/lib/libgtk-x11-2.0.so.0[0x536c387]
/usr/lib/libgtk-x11-2.0.so.0[0x536fcaa]
/usr/lib/libgtk-x11-2.0.so.0[0x536ffd1]
/usr/lib/libgtk-x11-2.0.so.0[0x53d3fad]
/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0x70bd9b]
/lib/libgobject-2.0.so.0[0x71c433]
/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0x71d957]
/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x71db19]
/usr/lib/libgtk-x11-2.0.so.0(gtk_tree_view_row_activated+0x61)[0x54c8781]
/usr/lib/libgtk-x11-2.0.so.0[0x54d7625]
/usr/lib/libgtk-x11-2.0.so.0[0x53d5a60]
/lib/libgobject-2.0.so.0[0x70a589]
/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0x70bd9b]
/lib/libgobject-2.0.so.0[0x71ca83]
/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x68f)[0x71d71f]
/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x71db19]
/usr/lib/libgtk-x11-2.0.so.0[0x54ea508]
/usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0x183)[0x53cee33]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x317)[0x53d0037]
/usr/lib/libgdk-x11-2.0.so.0[0x93112a]
/lib/libglib-2.0.so.0(g_main_context_dispatch+0x182)[0x686442]
/lib/libglib-2.0.so.0[0x68941f]
/lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0x6897c9]
/usr/lib/libgtk-x11-2.0.so.0(gtk_dialog_run+0x18b)[0x5350cbb]
/usr/lib/python2.4/site-packages/gtk-2.0/gtk/_gtk.so[0x1e9e52]
/usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x49a8)[0x6856f28]
/usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4d5d)[0x68572dd]
/usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4d5d)[0x68572dd]
/usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x845)[0x68581b5]
/usr/lib/libpython2.4.so.1.0[0x6809faa]
/usr/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0x67f1ec7]
/usr/lib/libpython2.4.so.1.0[0x67f8538]
/usr/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0x67f1ec7]
/usr/lib/libpython2.4.so.1.0(PyEval_CallObjectWithKeywords+0x7c)[0x68519dc]
/usr/lib/libpython2.4.so.1.0(PyObject_CallObject+0x2c)[0x67f2a4c]
/usr/lib/python2.4/site-packages/gtk-2.0/gobject/_gobject.so[0xf3e0c7]
/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0x70bd9b]
/lib/libgobject-2.0.so.0[0x71c433]
/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0x71d957]
/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x71db19]
/usr/lib/libgtk-x11-2.0.so.0(gtk_button_clicked+0x53)[0x5304e13]
/usr/lib/libgtk-x11-2.0.so.0[0x5306a5e]
/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x49)[0x7190f9]
/lib/libgobject-2.0.so.0[0x70a589]
/lib/libgobject-2.0.so.0(g_closure_invoke+0x20d)[0x70be7d]
/lib/libgobject-2.0.so.0[0x71c8ca]
/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0x71d957]
/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x71db19]
/usr/lib/libgtk-x11-2.0.so.0(gtk_button_released+0x53)[0x5304ea3]
/usr/lib/libgtk-x11-2.0.so.0[0x5304f01]
/usr/lib/libgtk-x11-2.0.so.0[0x53d5a60]
/lib/libgobject-2.0.so.0[0x70a589]
/lib/libgobject-2.0.so.0(g_closure_invoke+0x20d)[0x70be7d]
/lib/libgobject-2.0.so.0[0x71ca83]
/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x68f)[0x71d71f]
/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x71db19]
/usr/lib/libgtk-x11-2.0.so.0[0x54ea508]
======= Memory map: ========
00110000-002e1000 r-xp 00000000 fd:00 620164    
/usr/lib/python2.4/site-packages/gtk-2.0/gtk/_gtk.so
002e1000-00306000 rwxp 001d1000 fd:00 620164    
/usr/lib/python2.4/site-packages/gtk-2.0/gtk/_gtk.so
00306000-00370000 r-xp 00000000 fd:00 2896108    /usr/lib/libcairo.so.2.9.3
00370000-00372000 rwxp 00069000 fd:00 2896108    /usr/lib/libcairo.so.2.9.3
00372000-00375000 r-xp 00000000 fd:00 3072424   
/usr/lib/python2.4/site-packages/gtk-2.0/pangocairo.so
00375000-00376000 rwxp 00002000 fd:00 3072424   
/usr/lib/python2.4/site-packages/gtk-2.0/pangocairo.so
00376000-0037f000 r-xp 00000000 fd:00 2219560    /lib/libnss_files-2.5.so
0037f000-00380000 r-xp 00008000 fd:00 2219560    /lib/libnss_files-2.5.so
00380000-00381000 rwxp 00009000 fd:00 2219560    /lib/libnss_files-2.5.so
00381000-00384000 r-xp 00000000 fd:00 3010849   
/usr/lib/python2.4/lib-dynload/cStringIO.so
00384000-00385000 rwxp 00003000 fd:00 3010849   
/usr/lib/python2.4/lib-dynload/cStringIO.so
00385000-00387000 r-xp 00000000 fd:00 2220394    /lib/libutil-2.5.so
00387000-00388000 r-xp 00001000 fd:00 2220394    /lib/libutil-2.5.so
00388000-00389000 rwxp 00002000 fd:00 2220394    /lib/libutil-2.5.so
00389000-0038d000 r-xp 00000000 fd:00 3106667   
/usr/lib/python2.4/site-packages/gtk-2.0/gtk/glade.so
0038d000-0038e000 rwxp 00003000 fd:00 3106667   
/usr/lib/python2.4/site-packages/gtk-2.0/gtk/glade.so
0038e000-003a7000 r-xp 00000000 fd:00 2219752    /lib/ld-2.5.so
003a7000-003a8000 r-xp 00018000 fd:00 2219752    /lib/ld-2.5.so
003a8000-003a9000 rwxp 00019000 fd:00 2219752    /lib/ld-2.5.so
003ab000-004e2000 r-xp 00000000 fd:00 2219755    /lib/libc-2.5.so
004e2000-004e4000 r-xp 00137000 fd:00 2219755    /lib/libc-2.5.so
004e4000-004e5000 rwxp 00139000 fd:00 2219755    /lib/libc-2.5.so
004e5000-004e8000 rwxp 004e5000 00:00 0 
004ea000-0050f000 r-xp 00000000 fd:00 2220385    /lib/libm-2.5.so
0050f000-00510000 r-xp 00024000 fd:00 2220385    /lib/libm-2.5.so
00510000-00511000 rwxp 00025000 fd:00 2220385    /lib/libm-2.5.so
00513000-00515000 r-xp 00000000 fd:00 2220383    /lib/libdl-2.5.so
00515000-00516000 r-xp 00001000 fd:00 2220383    /lib/libdl-2.5.so
00516000-00517000 rwxp 00002000 fd:00 2220383    /lib/libdl-2.5.so
00519000-0052c000 r-xp 00000000 fd:00 2220378   /usr/bin/fwbackups: line 18:
15799 Aborted                 python /usr/share/fwbackups/fwbackups-runapp.py "$@"

Well, the backtrace I have no idea why it happened or how to fix it... however
for  the Iter that's fine, that happens when there's no backup archives for it
to look at. This happens every time?

I haven't had the backtrace since the first run.

I was able to run a backup set.  Here are my results:

1) The GtkTreeIter traceback only happens, as you said, when there is no backup
archive.

2) There do not seem to be issues with with bug #233799 anymore

3) The application shows a busy cursor when it's busy.

4) The gui also properly updates itself when it's busy.

I assume you'll also want to know what went wrong.

1) Although the action buttons are disabled when they should be, the menu is not
and you can get to items that you shouldn't (ie. get to restore while a backup
is running).  Options button is also available when the backup is running.

2) Cancelling a backup job doesn't seem to do anything.  Eventually I had to
kill the application, and even then the backup job (tar process) continued until
I killed it too.

3) rsync is totally broken for me.  It terminates within the first two minutes
(after the actual file copy starts).    I would suspect a problem in running a
rsync to the destination but running rsync alone to backup manually has already
proven reliable for me.


Hmm... well now that I'm trying to reproduce it to get the error, it's
working... heh.

I've coded the fix for the menus and the Options button, it will be in the next
Beta release I make... As for the cancel, what happens is fwbackups will cleanly
finish the operation, and stop at defined checkpoints if a cancel is requested.
So if a cancel is requested, it will stop at the item in the list that occurs first:
- Execution of the Before command
- Creating package lists / disk info
- Any backup path
- Compressing the backup
- Execution of the After command
This way nothing is left half-finished, at least there is some sort of solid result.

For #3, can I have the paths you are attempting to backup and your destination?
I'm not sure what is causing the failure, but I'll run "fake" tests with the paths.

(In reply to comment #9)
> As for the cancel, what happens is fwbackups will cleanly
> finish the operation, and stop at defined checkpoints if a cancel is requested.
> So if a cancel is requested, it will stop at the item in the list that occurs
first:
> - Execution of the Before command
> - Creating package lists / disk info
> - Any backup path
> - Compressing the backup
> - Execution of the After command
> This way nothing is left half-finished, at least there is some sort of solid
result.

I think that most people would expect Cancel to leave the backup in a
half-finished state.  Doesn't seem right to hit cancel and to have to wait for
hours.  Maybe a warning that it will be an unreliable backup and then just
terminate it?

 
> For #3, can I have the paths you are attempting to backup and your destination?
> I'm not sure what is causing the failure, but I'll run "fake" tests with the
paths.

I will investigate this more first.  The system that I was backing up
mysteriously died overnight after I posted this message (dead hard drive, dead
power supply).  I want to make sure it wasn't related to that.


RFE:  For rsync backups, please give the ability to not use dated directories. 
That way, a fast sync can be setup that just snapshots the data defined in the
backup job.  Also, the ability to use rsync over ssh would be superb.

Is there any way to easily test this kind of error.  This was caused when I ran
fwbackups with rsync across nfs.  On the nfs server I have squash_root, so
nothing can be mapped to uid 0 there.  This is the chaos that ensued.  The
backup also terminated, but fwbackups thought it was still running.

INFO :: Apr 03 00:52:37: fwbackups administrator started
INFO :: Apr 03 00:52:54: Starting automatic backup of set 'System Backup'
ERROR :: Apr 03 00:53:05: Error backing up path ''/opt'
"/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03"'
ERROR :: Apr 03 00:53:05: Output:
Return value: 23
stdout: []
stderr: ['rsync: chown
"/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03/opt" failed: Operation not permitted (1)\n', 'rsync error:
some files could not be transferred (code 23) at main.c(977) [sender=2.6.9]\n']
ERROR :: Apr 03 00:53:05: Error backing up path ''/srv'
"/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03"'
ERROR :: Apr 03 00:53:06: Output:
Return value: 23
stdout: []
stderr: ['rsync: chown
"/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03/srv" failed: Operation not permitted (1)\n', 'rsync error:
some files could not be transferred (code 23) at main.c(977) [sender=2.6.9]\n']
ERROR :: Apr 03 00:53:08: Error backing up path ''/root'
"/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03"'
ERROR :: Apr 03 00:53:08: Output:
Return value: 23
stdout: []
stderr: ['rsync: chown
"/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03/root" failed: Operation not permitted (1)\n', 'rsync: chown
"/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03/root/.config" failed: Operation not permitted (1)\n', 'rsync:
chown "/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03/root/.config/gtk-2.0" failed: Operation not permitted (1)\n',
'rsync: chown
"/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03/root/.dbus" failed: Operation not permitted (1)\n', 'rsync:
chown "/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03/root/.dbus/session-bus" failed: Operation not permitted
(1)\n', 'rsync: chown
"/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03/root/.fwbackups" failed: Operation not permitted (1)\n',
'rsync: chown
"/net/terastation/mnt/array1/backup/fwbackups-snowflake-root/Backup-System
Backup-2007-04-03/root/.fwbackups/Sets" failed: Operation not permitted (1)\n',
'rsync: chown 

If you run rsync (not from spawned from fwbackups-run) does it also fail?
For the SSH access, I'm planning to integrate GnomeVFS but that's for 1.44...

(In reply to comment #12)
> If you run rsync (not from spawned from fwbackups-run) does it also fail?
> For the SSH access, I'm planning to integrate GnomeVFS but that's for 1.44...

Sorry, I meant to followup on this earlier.  Yes, it does fail because of the
root_squash option on the nfs system.  Basically, it's trying to chown the files
to uid 0 which is not allowed.

Don't know if there is an easy way to catch this sort of thing though.

I'm not sure either - But what I do know for sure is that if this happens,
fwbackups shouldn't think the backup is still going... What's the exit status on
rsync after it fails?

(In reply to comment #14)
> I'm not sure either - But what I do know for sure is that if this happens,
> fwbackups shouldn't think the backup is still going... What's the exit status on
> rsync after it fails?

Looks like I misinterpreted it.  Apparently it did not terminate, it was still
running, just not spewing errors anymore.  Maybe it hit a big file and I was
impatient.  I just ran a smaller backup and it gave a chown error for each root
owned file, but the backup did finish.

Just to keep you updated, I haven't had much time on my hands lately and for the
next three weeks or so I'd guess it will be the same - But I'll work on this
when things clear up.

I've put Beta3 into development and the fc6 RPM I build with Mock as usual is at
www.diffingo.com if you'd like to test the new changes. As always, thanks!

I've been using the beta-2 rpm and everything is working very nicely.  I still
have some issues with my rsync backups, but haven't had a chance to determine
where the actual problem is (time constraints here as well).  I'll try to
upgrade to beta-3 here shortly.

Also, I'm going to move the RFE above to a separate ticket so it's easier to track.

I've just submitted fwbackups-1_43_0-0_1_rc2_fc6 for building... I'll close this
ticket.