launching backintime fails to start

Reported by Stuart Colville on 2009-08-05
118
This bug affects 19 people
Affects Status Importance Assigned to Milestone
Back In Time
Undecided
Unassigned
backintime (Ubuntu)
Medium
Unassigned
Declined for Karmic by Iulian Udrea
Declined for Lucid by Iulian Udrea

Bug Description

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.

tags: added: 0.9.26
pinzia (pinzia) wrote :

same bug on kde 4.3 (kubuntu karmic alpha 3)

Changed in backintime:
status: New → Confirmed
Bart de Koning (bratdaking) wrote :

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)?

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

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.
>

Changed in backintime:
status: Confirmed → Fix Committed

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?

summary: - launching backintime as root fails to start
+ launching backintime fails to start
Richard Bailey (rmjb) on 2009-10-16
Changed in backintime (Ubuntu):
status: New → Fix Committed
Richard Bailey (rmjb) wrote :

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) wrote :

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

Thanks!

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) wrote :

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) wrote :

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) wrote :

This bug makes me sad!

Dan (danleweb) wrote :

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

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) wrote :

Approved. Subscribing ubuntu-sponsors.

Iulian Udrea (iulian) wrote :

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

Stefano Rivera (stefanor) wrote :

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

Changed in backintime (Ubuntu):
importance: Undecided → Medium
status: Fix Committed → Confirmed
mike (ubuntu-holmesfamily) wrote :

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) wrote :

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.

Dan (danleweb) on 2010-09-12
Changed in backintime:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in backintime (Ubuntu):
status: Confirmed → Fix Released
Frank Bicknell (fbicknel) wrote :

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) wrote :

Fix for 10.04 LTS? It is still suported version!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers