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 {at}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