* 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.
---