The two truly severe bugs in 2.5.5.0

[cgreevey]

There are two truly serious bugs in 2.5.5.0. Are these known and going to be fixed in 2.5.6.0?

Bug #1: Selecting "clear completed" on the transfers tab can delete files.

Specifically, it seems to happen if a file was sufficiently-recently downloaded and moved to the destination folder. That file may disappear from that folder if "clear completed" is done. It can be prevented by moving everything out of the destination folder (such as by sorting the files into more permanent homes within one's library) first, or (I think) by waiting long enough after the most recent download is complete.

When this happens, the file disappears and a thorough hard drive search won't find it. Nor is it in the recycle bin. It will turn brown in the search result list where you found it, if that's still open in Shareaza. The only way to recover it seems to be to re-download it.

Since this bug deletes files from the user's hard disk without permission, it's easily the most serious bug in Shareaza.

Fix: Find out what code can delete a library file, and what code paths can trigger such code. Remove all such code paths that don't involve the user explicitly telling Shareaza to delete the file. Clear Completed should never, in particular, delete any files. Selecting a partial download and hitting Cancel is the only thing that should delete files from the transfer tab, and then only if the user okays a confirmation prompt.

Bug #2: Shareaza crashes if you hit F8, select all G2 hosts, and hit delete.

This seems to be an array overrun error caused because it keeps the same item position highlighted. If you have selected item #300 in the list, it keeps item #300 as the position of the selection after the delete. If there were 700 items, you'll now be 3/4 of the way down the list instead of at the top. If there were only 300, the list is now shorter than the distance to the selection, and that seems to cause the crash.

The annoying workaround is to delete less than half the hosts at a time, and only one at a time once it is down to only a handful of items, when clearing the host cache.

Fix: Get rid of the array overrun by clamping the cursor position in the list to its new size after a delete. So if there are 400 items and you select to 300 and delete, the cursor position will be 100 rather than 300 afterward.

This bug is made somewhat worse by another bug that causes one to need to clear the host cache fairly often, two to three times a week. Since that bug is related to one of these two most serious bugs, I'll include it below.

Bug #3: "red flag disease".

This is an odd one. From time to time, and without apparent provocation, Shareaza will become poorly connected with a constellation of related symptoms (high CPU use, for one, as well as the obvious one of poor search results). The status line will show one or two fewer neighbors than normal and may keep fluctuating. The Network tab will show that G2 is partly or wholly disconnected, with a large number of attempts to reestablish a connection, but the attempts will keep timing out. Once in a while one will connect briefly but immediately disappear, lasting no more than one or two seconds. It's as if G2 has "become slippery" in some way, so it grabs for a connection but can't hang onto one for any length of time and with most attempts doesn't grasp one even briefly. The host cache will show that the usual mixture of diverse country flags has been replaced by one uniform color: red. It's not all one single flag though; there're three or four that will show up when it's in this state. But they all are largely or entirely red, except one is a red spot on white.

Only disconnecting G2, clearing the host cache, and reconnecting G2 will fix this, and only temporarily. It will happen again in anywhere from a few hours to a day or three. So this seems to be caused by a bad bootstrap that gives bogus G2 hosts when queried the addresses of which all come from a few particular geographic areas.

Fix: Add the misbehaving bootstrap to the in-built "blocked" list, or if it can't be readily identified or keeps moving around or something just make the G2 connection thing treat all addresses from countries with red-dominated flags as invalid. There are enough G2 hubs in the countries with blue, green, etc. flags that this shouldn't impair connectivity much, and Shareaza should still connect to *sources* and *downloaders* anywhere in the world, just not *hubs*. (I think you can exclude Canada from the ban; I've never seen its distinctive red leaf on white in "red flag disease". Only red spot on white, as a sprinkling on ones that are pretty much just red or a bit of something else on red. On the other hand I don't see many Canadian flags on the hosts or network tab regardless.)

[old_death]

[cgreevey]

[old_death]

No, you got me wrong. It's an other client that's popular in these countries. It uses G2 with a non-standard extension that prevents us from connecting to them... Which also means the clients are basically compatible, so that the IPs of one can be forwarded to the other and the other way around - however interconnections cannot be established.

[cgreevey]

[cyko_01]

[old_death]

What I suggested was a quick'n'dirty solution which is valid as long as Shareaza trusts IPs it has never seen online and spreads them to other Shareaza clients... I know that it is far from being optimal - although I have to point out that there hasn't been a good Chinese translation of Shareaza for years anyway...