Tiger-tree request returning erroneous 404 errors

[Lanigiro]

Here's an odd one for you. I've got a bunch of smallish files (a meg or so each) I'm trying to get and I keep finding them partially downloaded with "Searching (No Sources)" status. Every so often one gains a chunk of exactly 128K. Using Downloads.NeverDrop didn't help; I hoped it would then get all of each file it got any of, but it continued to just occasionally find the file, add 128K more, and lose it again with each one.

Then, I found them again with search and added the source back, and watched what happened.

Each connected in turn, downloaded the next 128K of the file, and then requested a tiger tree hash, as Shareaza does with G2 downloads after a 128K chunk if it hasn't got a tiger tree for that file yet and the file isn't done yet. The source then responded with a 404 and Shareaza dropped it, then moved on to the next file.

I thought it might be some sort of incompatibility with a remote peer that didn't understand tiger tree requests, but when another one started downloading I expanded the little + thingy and apparently it's Shareaza 2.7.1.0 at both ends.

So, apparently under some circumstances Shareaza 2.7.1.0 will incorrectly give a 404 in response to a tiger tree request for a file that it does have and is sharing; a file for which a request for an actual chunk of the actual file gets satisfied. Moreover, this seems to be the consistent behavior of some specific subset of 2.7.1.0 peers, rather than a random thing or a consistent behavior of all 2.7.1.0 peers. Probably it's triggered by some nondefault setting. I have no idea which and 2.7.1.0 has a metric truckload of settings under "advanced" so it's probably easier to track this one down by backward-chaining from where Shareaza responds to TTH requests and answering the question "how does it get here in such a state that it has the file, will upload the file, but responds here with a 404?", then going a step back to find out how it gets to that step in such a state that it will then get to the final step in the state producing the bogus 404, and so on until the corner-case that's causing the problem becomes obvious, hopefully along with how to fix it so it will send the TTH instead of a 404 in these cases.

[old_death]

This might be something interesting for Rasporov/Ryo-oh-ki to ponder over.