launching backintime fails to start

[Stuart Colville]

running "Back In Time (root) from applications -> System Tools the window appears and dissappears and fails to start

Running it from the CLI I get the following traceback:

Back In Time
Version: 0.9.26

Back In Time comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type `backintime-gnome --license' for details.

Traceback (most recent call last):
  File "/usr/share/backintime/gnome/app.py", line 1056, in <module>
    main_window = MainWindow( cfg, app_instance )
  File "/usr/share/backintime/gnome/app.py", line 281, in __init__
    self.update_all( True )
  File "/usr/share/backintime/gnome/app.py", line 388, in update_all
    self.update_folder_view( 1, selected_file, show_snapshots )
  File "/usr/share/backintime/gnome/app.py", line 1000, in update_folder_view
    new_iter = self.store_folder_view.append( [ item[0], rel_path, item[3], item[5], item[1], item[2], item[4] ] )
TypeError: value is of wrong type for this column

Wrapping try/except around line 1000 prevents the error and it starts correctly.

[pinzia (pinzia)]

same bug on kde 4.3 (kubuntu karmic alpha 3)

[Bart de Koning (bratdaking)]

I might have found the actual problem, and why this bug is not occuring often:
if it encounters a huge file (in my case if the file was 3 GB), while populating the list for the folder view, it gives an TypeError for item[4], which is the size in bytes. If the program is already running it will just continue, however if it just starts than it crashes, failing to start the GUI completely.

I modified app.py a bit to show item[4] in line 1000 (when it builds the folder view):
  #populate the list
  self.store_folder_view.clear()

  selected_iter = None
  for item in files:
   rel_path = os.path.join( self.folder_path, item[0] )
   print "item[4]: %s" % item[4]
   new_iter = self.store_folder_view.append( [ item[0], rel_path, item[3], item[5], item[1], item[2], item[4] ] )
   if selected_file == rel_path:
    selected_iter = new_iter

# backintime-gnome

...
item[4]: 4096
item[4]: 3454
item[4]: 4096
item[4]: 1698
item[4]: 4096
item[4]: 4096
item[4]: 3468220579
Traceback (most recent call last):
  File "/usr/share/backintime/gnome/app.py", line 756, in on_btn_fodler_up_clicked
    self.update_folder_view( 1 )
  File "/usr/share/backintime/gnome/app.py", line 1001, in update_folder_view
    new_iter = self.store_folder_view.append( [ item[0], rel_path, item[3], item[5], item[1], item[2], item[4] ] )
TypeError: value is of wrong type for this column

Replacing item[4] in the new_iter line to something like 2000000000 solves the problem, replacing into 3000000000 makes it fail completely: apparently the memory space is too short for item[4].
item[4] holds the information for the size of the file in bytes, apparently now limited to slightly over 2 GB (most probably 2147483647 the max of a long), archives (like the one in my example above) or movies, easily go beyond that limit. Actually I don't know how to initialize item[4] for a bigger integer, is there any python equivalent to a long long, that will set the limit to 9 EB (ExaBytes)?

[Stuart Colville (muffinresearch)]

It would appear that something your hitting the sys.maxint limit which is the max of int

>>> import sys
>>> sys.maxint
2147483647

So you actually need these to be long not int.

if you change:

    self.store_folder_view = gtk.ListStore( str, str, str, int, str, str, int )

to:

    self.store_folder_view = gtk.ListStore( str, str, str, int, str, str, long )

That might solve it

[Bart de Koning (bratdaking)]

Thanks! Changing in line 212:
  self.store_folder_view = gtk.ListStore( str, str, str, int, str,
str, long )
did not work actually, however:
  self.store_folder_view = gtk.ListStore( str, str, str, int, str,
str, float )

So making it a float instead of a normal integer did do the trick!!!

2009/8/14 Stuart Colville <email address hidden>

> It would appear that something your hitting the sys.maxint limit which
> is the max of int
>
> >>> import sys
> >>> sys.maxint
> 2147483647
>
> So you actually need these to be long not int.
>
> if you change:
>
> self.store_folder_view = gtk.ListStore( str, str, str, int, str,
> str, int )
>
> to:
>
> self.store_folder_view = gtk.ListStore( str, str, str, int, str,
> str, long )
>
> That might solve it
>
> --
> launching backintime as root fails to start
> https://bugs.launchpad.net/bugs/409130
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Bart de Koning (bratdaking)]

Thanks! Changing in line 212:

  self.store_folder_view = gtk.ListStore( str, str, str, int, str,
str, long )
did not work actually, however:

  self.store_folder_view = gtk.ListStore( str, str, str, int, str,
str, float )

So making it a float instead of a normal integer did work out: it is able to read larger files now...
I changed the status to Fix committed, that is OK right?

[Richard Bailey (rmjb)]

To Karmic release deciders, this is a simple one line fix for a common bug with this version of Back in Time.

When karmic is out this bug will most likely affect a lot of new users that will start to use Back in Time because it's in Ubuntu's repos.

[Ben Andersen (ben72)]

This still appears in Karmic updated with all the latest. Shouldn't the fix be released? The fix in #5 works here.

Thanks!

[Jonathan Wiltshire (jwiltshire)]

On Mon, Feb 22, 2010 at 07:23:06PM -0000, Ben Andersen wrote:
> This still appears in Karmic updated with all the latest. Shouldn't the
> fix be released? The fix in #5 works here.

If you prepare a patch against the Karmic package and follow the SRU
guidelines [1] I'm sure ubuntu-sru will help you get it published.

1: https://wiki.ubuntu.com/StableReleaseUpdates

--
Jonathan Wiltshire

1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51

[Jonathan Wiltshire (jwiltshire)]

Sponsors, release deciders:

Impact
--------
In Karmic and Lucid packages of Backintime, large files can cause an overflow while listing them in the folder view.

TEST CASE:
----
With a large (>= 3Gb) file on disk, instruct BiT to display it in folder view.

Fix: http://bazaar.launchpad.net/~bratdaking/backintime/bug-409130/revision/614
-----
The patch in this upstream branch in an above post uses a float instead of an int to prevent an overflow. Sponsorship is required because I am not a Ubuntu developer.

Regression potential is low. This fix has received some testing in Debian and Ubuntu and I propose to fix it in Lucid for further testing before backporting the fix to Karmic.

[PhilGil (pgilston)]

As of today this bug is still present in Lucid RC. I have edited the app.py file per the instructions in post #5 and all is well so far.

[Johan Kröckel (jnkl)]

This bug makes me sad!

[Dan (danleweb)]

You can try the beta version from testing repository: http://backintime.le-web.org/download_page/

[JohnA (ubuntu-launchpad-online-catmanchest)]

I'm running Ubuntu 10.04 (lucid), BackInTime 0.9.26. Made the app.py line 212 fix (int to float) as in #5, and BiT is working fine now, running as root. Thanks for the postings, all.

[Iulian Udrea (iulian)]

Approved. Subscribing ubuntu-sponsors.

[Iulian Udrea (iulian)]

Actually, it doesn't even need an FFe because it's a bug-fix only upload.

[Stefano Rivera (stefanor)]

Unsubscribing sponsors, as there appears to be no action for us. Please prepare a debdiff or UDD merge and re-subscribe sponsors when ready.

[mike (ubuntu-holmesfamily)]

I just loaded 10.10 maveric beta and after a couple of days use I am experiencing a similar problem.
I had configured a profile using the menu and the root gui and the normal gui buttons - I was trying to find out why I needed both, I still don't know :-)

Any how, as root I can launch the gui, but the non root gui in the menu flashes open on the screen and the closes, without leaving a trace in the sys logs.

I appear to be able to sun backupintime ok from the CLI, in desperation I even performed a complete install and re install.

Is there a way I can dig into this further, since reinstalling failed for me I assume I would have to nuke the 10.10 install completely to fix this.

I also assume the GUI is trying to tell me I did something stupid, but I don't know where to look for the message basically.

[Dan (danleweb)]

BIT 0.9.26 has this bug (does't matter wich version of Ubuntu are you using).
If you want you can try beta version.

[Launchpad Janitor (janitor)]

This bug was fixed in the package backintime - 1.0.6-1

---------------
backintime (1.0.6-1) unstable; urgency=low

  * New upstream release (LP: #675696)
  * Don't create empty directories during build (patch no-empty-
    figures.patch) (LP: #696663)
  * Upload to unstable

backintime (1.0.4-1) experimental; urgency=low

  * New upstream release
      Closes: #555293
      LP: #409130 #507246 #528518 #534829 #522618
  * Update debian/copyright
  * The following patches are either integrated or fixed properly
    upstream: no-chmod-777.patch allow-root-backup.patch
  * Refactor remaining patches and make the headers DEP-3 compliant
  * Convert to source format 3.0 (quilt) and drop quilt dependency and
    logic
  * Don't depend on a specific version of Python; let dh_python choose
    the best option
  * Remove the "earlier-than" restriction for the Conflicts on
    backintime-kde4
  * Standards version 3.9.1 (no changes required)
  * Update my email address
 -- Jonathan Wiltshire <email address hidden> Mon, 10 Jan 2011 16:47:17 +0000

[Frank Bicknell (fbicknel)]

I have found that a directory with a 9GB file and a 1GB file showed only the 9GB file in the GUI. If I run the GUI from the command line:

sudo su-to-root -X -c backintime-gnome

I get messages very similar to those mentioned in this bug. The GUI does not crash, it (usually) silently leaves some large files out.

If I make the change (to float) in post #5, it fixes the problem.

Just posting this in case anyone has problems with missing files in the gui that are clearly in the saved backup set.

I'm running version 0.9.26-4.

[vadimo (michalgejdos-azet)]

Fix for 10.04 LTS? It is still suported version!