Does Shareaza ...

[grey-hame]

... still have the bug where, if multiple copies of the same file are in the library, and some are shared and some are not, Shareaza will return hits for that file over the network but refuse to upload it? (The correct behavior, of course, is that if any copies are shared it should both return hits for the file and upload it merrily.)

[old_death]

I've never heard of that bug... when has it been reported for the first time?

[grey-hame]

Years ago, before the forum was moved.

I'm pretty sure I'm seeing at least some peers consistently returning particular search results (suggesting they're reliably online) but returning 403/404 when the file is requested (to judge by my copy of Shareaza forgetting the source promptly, as well as never downloading the file, even with Downloads.NeverDrop turned on).

If the source was unreliable, the search result should only show up intermittently, and I should eventually get the file when my timing is good (particularly likely if I double click the search result within minutes or even seconds of receiving it, which I have done repeatedly now).

If the source deleted or otherwise quit sharing the file between my search and my attempt to download, the file shouldn't show up again for subsequent searches.

The peers I see that seem to be doing this all report themselves to be Shareazas.

So it looks like there is some circumstance in which Shareaza will repeatedly furnish a search hit but will refuse to serve the file -- that is, where it will have a file in its library, regard it as shared for the purposes of search, but regard it as non-shared for the purposes of upload. Further, either there's a lot of old un-updated Shareazas floating around out there and seeing regular use, or such a problem exists in recent versions, perhaps even 2.5.2.0.

If so it's easy to fix: make sure the search hit-returning pathway and the upload request-validating pathway call the same single function to decide whether a given file exists as far as sharing is concerned.

(Some additional complication is needed to deal with Shareaza's ghost-files feature, such that "ghost hits" are still sent for files that were rated but weren't kept, while also the receiving Shareaza must distinguish between "ghost hits" for which the querent lacks the file and real search results, so the "ghost hits" will tack on review and rating data on search results with other sources, but will not incorrectly produce visible search results all by themselves without any actual, usable sources. "Ghost hits" should simply have a "not-a-source" flag set if the sending peer lacks the file, so they can be not counted as a source by the receiving peer, and then the existing filter "minimum sources" set to 1 (the default) or greater will take care of preventing any file having only "ghost hits" from showing up in the receiving peer's UI as a spurious, unusable search result -- otherwise, we'll have a bug like this one again. Meanwhile, when there are actual sources, a search result may appear (modulo other filtering) and then the reviews and ratings in the "ghost hits" will contribute to the file's metadata.)

[grey-hame]

Well?

[ocexyz]

[grey-hame]

Why don't you do that? You presumably have access to it, and regardless, you're familiar with it. It would take you less time than it would take me. And it would probably be taken more seriously if it had your name on it.

[ocexyz]