file resumes with different hash !

darwusch · Post by **darwusch** » 2004-04-12 06:30

I just noticed that DC resumed a file with different hash. (version 0.402)
The files had identical name and exact size but the hash was totally different...
I understand that the hash can be different with a minor change, but could this be because the id tag (it was a mp3 file) from the song was different ?
So in other words:
Do mp3 files get a different hash if ONLY the ID3 tag is different ?
Cause then I understand why in this case, it was no problem for the file to resume with a different hash, even though it was not ment to be like this.

Todi · Post by **Todi** » 2004-04-12 06:36

If anything in the file contents is different, the hash will be different (afaik). So yes, changing the id tag would do that. Try downloading them separately and checking.

Post by **GargoyleMT** » 2004-04-12 13:06

Odd... it shouldn't add files with the wrong hash. Do you have any idea how the file came to be a source?

In a version or two, this shouldn't be a problem, since incremental verification will be around, but in the meantime...

darwusch · Post by **darwusch** » 2004-04-12 17:02

The file with another hash became a source after I used the "search for alternates" from the download queue.
And this was with the latest CVS files (april 12th)

Post by **GargoyleMT** » 2004-04-13 18:52

Oy, that's interesting, void QueueManager::onAction(SearchManagerListener::Types type, SearchResult* sr) seems to make no attempt to check for incompatible TTHes when matching by filename. I wonder if something like this would be better?

Code: Select all

			if(sr->getTTH() && qi->getTTH()) {
				if (*sr->getTTH() == *qi->getTTH()) {
					found = true;
					exact = true;
				}
			}

That should be fairly safe - if you start a download without a root TTH, autosearch shouldn't pick one up unless you match an XML list with the same filename. The QueueManager::add() will add a root to a non-existent one, but I suspect that can only be triggered by a manual add in the search frame.

Hmm, time to move this, I think.