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()
...
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)?
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): store_folder_ view.clear( )
#populate the list
self.
selected_iter = None folder_ view.append( [ item[0], rel_path, item[3], item[5], item[1], item[2], item[4] ] )
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
... backintime/ gnome/app. py", line 756, in on_btn_ fodler_ up_clicked update_ folder_ view( 1 ) backintime/ gnome/app. py", line 1001, in update_folder_view folder_ view.append( [ item[0], rel_path, item[3], item[5], item[1], item[2], item[4] ] )
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)?