* Originally in bama
* Crossposted in fidosoft.husky

31 Oct 16 21:21, you wrote to me:

 WV>>> Dupes have by definition the same dupe-checksum as the original, so
 WV>>> storing them is useless!

 ml>> maybe to you but to another developer who may be doing other things
 ml>> than /just/ dupes, it may be needed or desired... don't be so square
 ml>> that your mind is closed to other possibilities and thought
 ml>> processes... perhaps someone is keeping count of duplicate MSGIDs and
 ml>> needing also to store the CRC/hash for each of them...

 WV> If the CRC/hash is the same, because it's a dupe, you don't have to
 WV> store it again.

like i said before, that depends on the database format...

 WV> If you want to keep count of duplicate MSGID's you store those, or
 WV> just a count of them. That's got little to do with dupe hash's...

they can easily be stored and counted in the same database... who are you or i
to say that that is wrong? ;)

 ml>> example: yesterday i saw two messages with exactly the same MSGID,
 ml>> header, time stamps, and what looks to be the exact same message
 ml>> body... the seenbys and paths were different yet HPT with its
 ml>> HASH+MSGID dupe checking missed seeing the second one as a dupe...
 ml>> both were back-to-back in my message base so it was easy to flip back
 ml>> and forth between them to try to see any differences... golded+'s
 ml>> [I]nfo showed that they were virtually identical but there looked to
 ml>> be one space character immediately after the MSGID that was in one
 ml>> post and not the other... now, get this, both MSGIDs, even though
 ml>> they are the same, are in the dupe database but with different
 ml>> hashes...

 WV> I fail to see what's your point here. They weren't dupes according to
 WV> hpt, so the different crc/hash's were stored.

the point is that they ARE dupes and should have been detected as dupes...
someone's formula is incorrect... it reminds me of a mailer/tosser combo that
takes the header plus the first 40 bytes to calculate their hash with...
software developers need to know about this so they can take steps to put the
data in the proper place so this particular software will see the data and
catch dupes as needed... this means to place the MSGID at the top or just
after the AREA tag... but see? this is the type of knowledge that is gained
after years of working with FTN software and being aware of how things were
done in the past... not assuming that everything is done the same
everywhere... especially since many developers are now gone and their
knowlegede is no longer first or second hand... even with new developers
having taken over older software and the details of the operation not having
been transmitted along with the actual code base... the new maintainers have
to figure it out for themselves or be told by someone that knows these
details... reading the code is one thing... understanding it and why it was
done a certain way is another...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... I'm not an asshole. I'm a hemorrhoid. I irritate assholes.
---
 * Origin:  (1:3634/12.73)