launching backintime fails to start
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Back In Time |
Fix Released
|
Undecided
|
Unassigned | |
| backintime (Ubuntu) |
Medium
|
Unassigned | ||
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/
main_window = MainWindow( cfg, app_instance )
File "/usr/share/
self.
File "/usr/share/
self.
File "/usr/share/
new_iter = self.store_
TypeError: value is of wrong type for this column
Wrapping try/except around line 1000 prevents the error and it starts correctly.
Related branches
- Dan: Pending requested 2009-08-17
- Diff: None lines
tags: | added: 0.9.26 |
pinzia (pinzia) wrote : | #1 |
Changed in backintime: | |
status: | New → Confirmed |
Bart de Koning (bratdaking) wrote : | #2 |
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.
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_
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/
self.
File "/usr/share/
new_iter = self.store_
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) wrote : | #3 |
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.
to:
self.
That might solve it
Bart de Koning (bratdaking) wrote : Re: [Bug 409130] Re: launching backintime as root fails to start | #4 |
Thanks! Changing in line 212:
self.
str, long )
did not work actually, however:
self.
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_
> str, int )
>
> to:
>
> self.store_
> str, long )
>
> That might solve it
>
> --
> launching backintime as root fails to start
> https:/
> 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.
str, long )
did not work actually, however:
self.
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 |
Changed in backintime (Ubuntu): | |
status: | New → Fix Committed |
Richard Bailey (rmjb) wrote : | #6 |
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 : | #7 |
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:/
--
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 : | #9 |
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://
-----
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 : | #10 |
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 : | #11 |
This bug makes me sad!
Dan (danleweb) wrote : | #12 |
You can try the beta version from testing repository: http://
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 : | #14 |
Approved. Subscribing ubuntu-sponsors.
Iulian Udrea (iulian) wrote : | #15 |
Actually, it doesn't even need an FFe because it's a bug-fix only upload.
Stefano Rivera (stefanor) wrote : | #16 |
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 : | #17 |
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 : | #18 |
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.
Changed in backintime: | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #19 |
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-
* 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 : | #20 |
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 : | #21 |
Fix for 10.04 LTS? It is still suported version!
same bug on kde 4.3 (kubuntu karmic alpha 3)