TIP: Click on subject to list as thread! ANSI
echo: tub
to: All
from: Bob Jones
date: 2003-07-26 19:18:04
subject: Linux Squish Dupecheck Bug fix

cc: MUFFIN echo
cc: Wes Garland 1:249/128
cc: Bo Simonsen 2:236/100

All users of the *nix port of Squish:

The code to fix the dupe check bug is now checked in to the SourceForge
developer CVS server, and should be available on the SourceForge public
server in 24 hours.  Once the code is availabe, run a CVS Update against
the server.  I've updated four files as part of this change, including the
version ID that squish prints out to reflect this change.  You will also
get updates I recently checked that Bo Simonsen provided to me.

If you have been using Squish/Unix 1.12.001 BETA or earlier versions you
need to update your code and recompile to correct this bug, or switch to
just using 

DupeCheck Header

instead of other DupeCheck options in your squish.cfg file.

THIS ONLY IMPACTS THE Squish *nix port.  There is no impact to the DOS,
OS/2 or Win32 systems.  The error comes out of the changes made to port the
code to Linux.  If anyone has been compiling the Squish Unix port on DOS,
OS/2 or Win32 platforms for their personal usage, please let me know.  I'd
like to get you involved in helping the Maximus team keep the code
compilable in those environments.  

By running the CVS Update from the Sorceforge server, you will also get Bo
Simonsen's code fixes for a few other errors.  I'll have to dig out that
documentation.  [Fixed a packet file name case issue under Unix
environment.  Fixed a path problem that caused a message deletion to fail
(/ vs \ issue).  Fixed an OS_2 define typo.  Don't remember anything else
off the top of my head.]

The old code was only reading the first part of the MSGID.  On at least
some messages, it was only reading the first hex digit of the serial
number, and then calling messages duplicates based on just the first digit
of the MSGID number instead of all 8 (hex) digits.

Once I re-enabled my dupe checking (and returned my maximum number of dupes
to keep per message area), the code started correctly catching dupes.  I
did not delete my old dupe database, but I had previously set the number of
dupes to retain to the minimum, so it won't take long for this system to
clean out the old data.  I'm currently testing using both MSGID and Header.
 In the current code (Squish/Unix version 1.12.002 Beta or later)  you can
use either MSGID or Header or both for dupe checking.  As far as I can
tell, there is no way to totally turn off the dupe checking via the
squish.cfg file using the current code.  

Take care....

Bob Jones, 1:343/41



 BJ> I finally found at least part of the bug in the dupe 
 BJ> checker in the port of Squish to Linux.  I'm now 
 BJ> testing the fix, but I'm not properly catching dupes 
 BJ> yet.  This should solve the problem of calling a number 
 BJ> of messages duplicates when they were not.  Basically, 
 BJ> the MSGID read on importing messages was not reading 
 BJ> the full 8 hex digits of the unique message id.  :( 

 BJ> Now that I've found this one, I expect there will be a 
 BJ> few other data errors that I haven't caught yet dealing 
 BJ> with reading and/or writing hexidecimal strings.  If 
 BJ> this message has an invalid Message ID string, then 
 BJ> that points to the same type of problem in another part of the code.....

 BJ> I'll post again once I've checked in the needed changes 
 BJ> to the sourceforge CVS server.  The changes will be 
 BJ> available from the public sourceforge CVS server 24 
 BJ> hours after the changes are checked in on the 
 BJ> sourceforge development server.  

 BJ> Note:  I believe existing dupe information for existing 
 BJ> databases are in error if you have used any of the 
 BJ> Squish / Unix ports to date.  So, when you update to 
 BJ> the corrected code, you probably should delete any 
 BJ> existing files containing the dupe check hash values....

 BJ> Take care.....

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)
SEEN-BY: 633/267 270
@PATH: 343/41 10/345 106/1 2000 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.