Subj : DUPES! To : Wilfred van Velzen From : mark lewis Date : Mon Oct 31 2016 22:33:26 * 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) .