[Pythonmac-SIG] Trying to track down a bug in BitTorrent for Mac OS 9

Phil phil at masstransfer.net
Sun Apr 11 03:28:54 EDT 2004


I have something of an oddball question, and would be grateful if someone
could help me out.  I'm trying to track down a bug that shows up when I run
BitTorrent for Mac OS 9, and I'm not sure whether it's a problem with
BitTorrent, MacPython, or some combination of both.

Basically, what happens is this:  in BitTorrent, when you resume
downloading after having stopped (say, to restart your computer), the
client checks the portion of the file you've already downloaded.  (I assume
it does this to test for corruption and so forth.)  Normally, under Windows
or OS X, this takes just a few minutes.

But for some reason, under OS 9, it takes an absurd amount of time --
something like 1 hour per 100 MB.  From what I understand, "checking [the]
existing file" is _not_ a computationally-intensive process, and shouldn't
take anything like the length of time it takes on Mac OS 9 (using the
btdownloadheadless.py client, which is the only one that works under OS 9).
As it stands now, if I'm interrupted near the end of an 800MB download, I
have to let my computer run overnight just to get back on!

Has anyone seen this bug before?  Any idea of what might cause it, or how
to fix it?  I've upgraded to the newest version of MacPython, and have
confirmed that the bug still shows up.  Alas, my expertise with
Python/programming is basically nil, so I'm lost in the woods here...

Thanks,
Phil

P.S.  Does anyone know of a workaround for dealing with .torrents with long
filenames under Mac OS 9?  Right now, my understanding is that if the
.torrent is made up of multiple files with long filenames, OS 9 users are
out of luck.





More information about the Pythonmac-SIG mailing list