On Mon Oct-31-2016 22:33, mark lewis (1:3634/12.73) wrote to Wilfred van Velzen:

 ml> {at}REPLY: 2:280/464 5817a8b8
 ml> {at}MSGID: 1:3634/12.73 58180133
 ml> {at}PID: GED+LNX 1.1.5-b20150715
 ml> {at}CHRS: CP437 2
 ml> {at}TZUTC: -0400
 ml> {at}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> {at}EEN-BY: 1/10 146 11/0 1 25/8 57/0 1 73/0 1 100/200 111/1 120/229
 ml> {at}EEN-BY: 120/301 302 323 502 544 545 546 640 123/57 500 130/505 138/146
 ml> {at}EEN-BY: 140/1 153/250 7715 154/10 199/0 1 200/1 203/0 220/10 221/0
 ml> {at}EEN-BY: 226/301 227/51 230/0 240/5832 249/303 261/38 266/512 275/100
 ml> {at}EEN-BY: 280/464 5003 288/34 317/2 342/17 77 352/0 3 393/68 423/120
 ml> {at}EEN-BY: 712/848 770/0 1 100 340 772/0 1 100 210 777/7 863/100 101
 ml> {at}EEN-BY: 902/508 2215/15 300 1701 2320/100 3828/7 4975/301
 ml> {at}ATH: 3634/12 123/500 261/38 393/68 770/1 280/464 227/51 120/544
 ml> {at}ATH: 140/1 3828/7


Regards,

Roger 
--- timEd/386 1.10.y2k+ W10 (1607)