25 Oct 12 04:45, I wrote to all:   
      
    ac> I might try getting sqconver to convert the base to *.MSG format, then   
    ac> back to Squish format.   
      
   More fun, as I discover that:   
      
   sqconver oldbase squish newbase '*.msg' 0   
      
   occasionally generates *.msg files with extranous nuls appended to the end:   
      
   00000390  35 2f 30 0d 01 50 41 54  48 3a 20 32 34 39 2f 33  |5/0..PATH: 249/3|   
   000003a0  30 33 20 32 32 39 2f 32  30 30 30 20 31 32 33 2f  |03 229/2000 123/|   
   000003b0  35 30 30 20 32 36 31 2f  33 38 20 36 33 33 2f 32  |500 261/38 633/2|   
   000003c0  36 30 0d 0d 00 30 30 20  32 36 31 2f 33 38 20 36  |60...00 261/38 6|   
   000003d0  33 33 2f 32 36 30 0d 0d  00 39 2f 33 30 33 20 32  |33/260...9/303 2|   
   000003e0  32 39 2f 32 30 30 30 20  31 32 33 2f 35 30 30 20  |29/2000 123/500 |   
   000003f0  32 36 31 2f 33 38 20 36  33 33 2f 32 36 30 0d 0d  |261/38 633/260..|   
   00000400  00 36 31 2f 33 38 20 36  33 33 2f 32 36 30 0d 00  |.61/38 633/260..|   
   00000410   
      
   ... which then cause sqconver to generate a corrupted .SQD file when the *.MSG   
   files are converted back to Squish format:   
      
   sqconver newbase '*.msg' newerbase squish 0   
      
   Possibly a case of GIGO, where the original Squish base was already partly   
   corrupt, but FTS-1 requires that a stored *.MSG file to have just a single nul   
   terminator at the end, so these aren't to spec. Arguably another MsgAPI bug.   
      
   Also, more of a cosmetic bug perhaps, but sqconver adds @INTL kludges to each   
   message, despite it being an echomail area (which is why I specified zero for   
   the fifth parameter).   
      
   Hmph.   
      
   One day I may write a sqconver-workalike in Python. Minus all the bugs...   
      
   --- GoldED+/BSD 1.1.5-b20110223-b20110223   
    * Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)