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