On Mon Oct-31-2016 22:33, mark lewis (1:3634/12.73) wrote to Wilfred van   
   Velzen:   
      
    ml> @REPLY: 2:280/464 5817a8b8   
    ml> @MSGID: 1:3634/12.73 58180133   
    ml> @PID: GED+LNX 1.1.5-b20150715   
    ml> @CHRS: CP437 2   
    ml> @TZUTC: -0400   
    ml> @TID: hpt/lnx 1.9.0-cur 07-09-15   
    ml> * Originally in bama   
    ml> * Crossposted in fidosoft.husky   
      
    ml> 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.   
      
    ml> 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...   
      
    ml> they can easily be stored and counted in the same database... who   
    ml> 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.   
      
    ml> the point is that they ARE dupes and should have been detected as   
    ml> dupes... someone's formula is incorrect... it reminds me of a   
    ml> mailer/tosser combo that takes the header plus the first 40 bytes   
    ml> to calculate their hash with... software developers need to know   
    ml> about this so they can take steps to put the data in the proper   
    ml> place so this particular software will see the data and catch dupes   
    ml> as needed... this means to place the MSGID at the top or just after   
    ml> the AREA tag... but see? this is the type of knowledge that is   
    ml> gained after years of working with FTN software and being aware of   
    ml> how things were done in the past... not assuming that everything is   
    ml> done the same everywhere... especially since many developers are   
    ml> now gone and their knowlegede is no longer  first or second hand...   
    ml> even with new developers having taken over older software and the   
    ml> details of the operation not having been transmitted along with the   
    ml> actual code base... the new maintainers have to figure it out for   
    ml> themselves or be told by someone that knows these details...   
    ml> reading the code is one thing... understanding it and why it was   
    ml> done a certain way is another...   
      
    ml> )\/(ark   
      
    ml> Always Mount a Scratch Monkey   
    ml> Do you manage your own servers? If you are not running an IDS/IPS   
    ml> yer doin' it wrong...   
    ml> ... I'm not an asshole. I'm a hemorrhoid. I irritate assholes. ---   
    ml>  - Origin:  (1:3634/12.73)   
    ml> @EEN-BY: 1/10 146 11/0 1 25/8 57/0 1 73/0 1 100/200 111/1 120/229   
    ml> @EEN-BY: 120/301 302 323 502 544 545 546 640 123/57 500 130/505 138/146   
    ml> @EEN-BY: 140/1 153/250 7715 154/10 199/0 1 200/1 203/0 220/10 221/0   
    ml> @EEN-BY: 226/301 227/51 230/0 240/5832 249/303 261/38 266/512 275/100   
    ml> @EEN-BY: 280/464 5003 288/34 317/2 342/17 77 352/0 3 393/68 423/120   
    ml> @EEN-BY: 712/848 770/0 1 100 340 772/0 1 100 210 777/7 863/100 101   
    ml> @EEN-BY: 902/508 2215/15 300 1701 2320/100 3828/7 4975/301   
    ml> @ATH: 3634/12 123/500 261/38 393/68 770/1 280/464 227/51 120/544   
    ml> @ATH: 140/1 3828/7   
      
      
   Regards,   
      
   Roger    
   --- timEd/386 1.10.y2k+ W10 (1607)   
    * Origin: NCS BBS - Houma, LoUiSiAna - (1:3828/7)