There was no minor bugs forum, so I am posting this here.
I found a minor bug with how BitTornado chooses the starting directory in its "Save As" dialog window. It seems to occur when I grab a .torrent file from two different sources that are really a torrent of the same file but with slightly different file names in the .torrent file. So when I go to resume the first .torrent with the second .torrent (totally different tracker but for the same file), I have to select the file in the "Save As" dialog box. When I do select a file then tell it to save it on it and it resumes, it resumes without problems, but the $HOME/.BitTorrent config file's "last_saved" setting gets set to the full path + the filename. When looking at the code a little, I noticed that in "btdownloadgui.py" of BitTornado 0.1.2 on line 1789 it says:
Code:
d = dl.GetPath()
if d == start_dir:
d = start_dir1
bucket[0] = d
d1,d2 = split(d)
if d2 == default:
d = d1
self.configfile.WriteLastSaved(d)
It seems as if somehow "d" is being assigned something that isn't being split() before being written to the config file.
I wrote up a little work around that seems to fix my minor bug and force it to write out the correct path (at least in SuSE Linux 9.0).
Here is a "diff -u" of btdownloadgui.py in BitTornado 0.1.2 and my modifications:
Code:
--- btdownloadgui.py.old 2004-04-03 22:13:25.000000000 -0500
+++ btdownloadgui.py.fixed 2004-04-03 23:09:49.000000000 -0500
@@ -1767,7 +1767,13 @@
else:
start_dir = self.configfile.configfileargs['last_saved']
if not isdir(start_dir): # if it's not set properly
- start_dir = '/' # yes, this hack does work in Windows
+ if exists(start_dir):
+ if isdir( split(start_dir)[0] ):
+ start_dir = split( start_dir )[0]
+ else:
+ start_dir = '/'
+ else:
+ start_dir = '/' # yes, this hack does work in Windows
if dir:
start_dir1 = start_dir
if isdir(join(start_dir,default)):
@@ -1793,6 +1799,10 @@
d1,d2 = split(d)
if d2 == default:
d = d1
+ if not isdir(d):
+ if exists(d):
+ if isdir( split(d)[0] ):
+ d = split(d)[0]
self.configfile.WriteLastSaved(d)
else:
This workaround also corrects the reading of the "last_saved" config option if it does have a full path and filename saved in it so it won't go back to using "/" just because of that.
What do you think of this minor patch?
Login
FAQ
Search
