• errors and how to fix?

    From Paul Hayton@3:770/100 to All on Sun Dec 4 21:26:58 2022
    Hi there

    I'm starting to see this error in my logs

    3 Dec:04:2022:21:23:21 Linking area NETMAIL
    A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield occured!
    A Dec:04:2022:21:23:22 JAM ERROR: wrongly sized subfield occured!
    A Dec:04:2022:21:23:23 JAM ERROR: subfield is suspiciously large! (1414879828 bytes)
    A Dec:04:2022:21:23:23 JAM ERROR: wrongly sized subfield occured!
    A Dec:04:2022:21:23:24 JAM ERROR: subfield is suspiciously large! (976302592 bytes)
    A Dec:04:2022:21:23:24 JAM ERROR: subfield is suspiciously large! (825360384 bytes)
    ----------------------- Sun 04 Dec 2022, hpt/lnx 1.9 2022-07-03
    1 Dec:04:2022:21:23:25 Start
    1 Dec:04:2022:21:23:25 Start packing...
    4 Dec:04:2022:21:23:25 EchoTossLogFile not found -> Scanning all areas
    4 Dec:04:2022:21:23:25 Scanning NetmailArea NETMAIL
    A Dec:04:2022:21:23:25 JAM ERROR: wrongly sized subfield occured!
    4 Dec:04:2022:21:23:25 Scanning NetmailArea NETMSG
    D Dec:04:2022:21:23:25 Statistics
    D Dec:04:2022:21:23:25 areas: 2 msgs: 54
    D Dec:04:2022:21:23:25 exported: 0
    E Dec:04:2022:21:23:25 Areas summary:
    1 Dec:04:2022:21:23:25 End

    when I view the message base using GoldED the last 4-5 messages are empty.

    is the base corrupt? How best to resolve?

    Any tips/advice appreciated.

    Best, Paul

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Stephen Walsh@3:633/280 to Paul Hayton on Mon Dec 5 21:55:52 2022

    Hello Paul!

    04 Dec 22 21:26, you wrote to all:

    3 Dec:04:2022:21:23:21 Linking area NETMAIL
    A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield occured!
    A Dec:04:2022:21:23:22 JAM ERROR: wrongly sized subfield occured!
    A Dec:04:2022:21:23:23 JAM ERROR: subfield is suspiciously large! (1414879828 bytes) A Dec:04:2022:21:23:23 JAM ERROR: wrongly sized subfield occured! A Dec:04:2022:21:23:24 JAM ERROR: subfield is suspiciously large! (976302592 bytes) A Dec:04:2022:21:23:24 JAM
    ERROR: subfield is suspiciously large! (825360384 bytes) ----------------------- Sun 04 Dec 2022, hpt/lnx 1.9 2022-07-03
    [...]
    Dec:04:2022:21:23:25 Areas summary: 1 Dec:04:2022:21:23:25 End

    when I view the message base using GoldED the last 4-5 messages are
    empty.

    Do you have a "-$m xxxx" on the line for that area, and have you been running sqpack?



    Stephen


    --- GoldED+/LNX 1.1.5-b20220409
    * Origin: Dragon's Lair BBS, Telnet: dragon.vk3heg.net (3:633/280)
  • From Stas Mishchenkov@2:460/5858 to Paul Hayton on Mon Dec 5 14:58:48 2022
    Hi Paul!

    Sunday December 04 2022 21:26, you wrote to All:

    I'm starting to see this error in my logs

    3 Dec:04:2022:21:23:21 Linking area NETMAIL
    A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield occured!
    A Dec:04:2022:21:23:22 JAM ERROR: wrongly sized subfield occured!
    A Dec:04:2022:21:23:23 JAM ERROR: subfield is suspiciously large!

    [...skipped...]

    when I view the message base using GoldED the last 4-5 messages are
    empty.

    is the base corrupt? How best to resolve?

    Any tips/advice appreciated.

    I would recommend storing netmail in OPUS MSG base and using https://brorabbit.g0x.ru/files/perl/maintmsg.pl

    Have a nice night.
    Stas Mishchenkov.

    --- Have You daily sexual life? Hide it proper from Your wife! ;)
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
  • From Tommi Koivula@2:221/360 to Paul Hayton on Tue Dec 6 21:29:08 2022

    04 Dec 22 21:26, Paul Hayton wrote to All:

    Hi there

    I'm starting to see this error in my logs

    3 Dec:04:2022:21:23:21 Linking area NETMAIL
    A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield occured!
    A Dec:04:2022:21:23:22 JAM ERROR: wrongly sized subfield occured!
    A Dec:04:2022:21:23:23 JAM ERROR: subfield is suspiciously large! (1414879828 bytes)
    A Dec:04:2022:21:23:23 JAM ERROR: wrongly sized subfield occured!
    A Dec:04:2022:21:23:24 JAM ERROR: subfield is suspiciously large! (976302592 bytes)
    A Dec:04:2022:21:23:24 JAM ERROR: subfield is suspiciously large! (825360384 bytes)
    ----------------------- Sun 04 Dec 2022, hpt/lnx 1.9 2022-07-03
    1 Dec:04:2022:21:23:25 Start
    1 Dec:04:2022:21:23:25 Start packing...
    4 Dec:04:2022:21:23:25 EchoTossLogFile not found -> Scanning all areas
    4 Dec:04:2022:21:23:25 Scanning NetmailArea NETMAIL
    A Dec:04:2022:21:23:25 JAM ERROR: wrongly sized subfield occured!
    4 Dec:04:2022:21:23:25 Scanning NetmailArea NETMSG
    D Dec:04:2022:21:23:25 Statistics
    D Dec:04:2022:21:23:25 areas: 2 msgs: 54
    D Dec:04:2022:21:23:25 exported: 0
    E Dec:04:2022:21:23:25 Areas summary:
    1 Dec:04:2022:21:23:25 End

    when I view the message base using GoldED the last 4-5 messages are empty.

    is the base corrupt? How best to resolve?

    I have seen the same. You could try to delete those empty messages with GoldED and then run "sqpack NETMAIL".

    'Tommi

    ---
    * Origin: rbb.fidonet.fi (2:221/360)
  • From Nil Alexandrov@1:16/101 to Tommi Koivula on Tue Dec 6 15:43:40 2022
    Hello, Tommi!

    Tuesday December 06 2022 21:29, from Tommi Koivula -> Paul Hayton, in URL @OFGHIUrl:

    I'm starting to see this error in my logs
    A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield occured!
    is the base corrupt? How best to resolve?

    The JAM base is definitely corrupted here, but the question is how you'vee ended up like this then?

    I have seen the same.

    Are you guys running some software not compatible with 64bit?
    I remember seeing this with the original jamlib which was a part of jamnntpd for example, that only worked on 32-bit machines or you have to compile it with -m32 flag.

    You could try to delete those empty messages
    with GoldED and then run "sqpack NETMAIL".

    That sounds like a workaround in absence of the database fix utility.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5
    * Origin: -=NIL BBS=- (1:16/101)
  • From Paul Hayton@3:770/100 to Stephen Walsh on Wed Dec 7 12:43:48 2022

    On 05 Dec 2022 at 09:55p, Stephen Walsh pondered and said...

    Do you have a "-$m xxxx" on the line for that area, and have you been running sqpack?

    No and no... I have some learning/reading to do.
    I ended up just deleting the base and starting over after copying the files to a temp folder

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Stas Mishchenkov on Wed Dec 7 12:44:06 2022
    On 05 Dec 2022 at 02:58p, Stas Mishchenkov pondered and said...

    Any tips/advice appreciated.

    I would recommend storing netmail in OPUS MSG base and using https://brorabbit.g0x.ru/files/perl/maintmsg.pl

    thanks will check this out Stas.. :)

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Tommi Koivula on Wed Dec 7 12:44:24 2022
    On 06 Dec 2022 at 09:29p, Tommi Koivula pondered and said...

    I have seen the same. You could try to delete those empty messages with GoldED and then run "sqpack NETMAIL".

    Thanks for this tip Tommi :)

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Stas Mishchenkov@2:460/5858 to Paul Hayton on Wed Dec 7 09:29:52 2022
    Hi Paul!

    Wednesday December 07 2022 12:44, you wrote to me:

    Any tips/advice appreciated.

    I would recommend storing netmail in OPUS MSG base and using
    https://brorabbit.g0x.ru/files/perl/maintmsg.pl

    thanks will check this out Stas.. :)

    I don't know for what reason, but it seems to me that storing netmail in jam or squish is unnatural for it. I've noticed that this isn't the first time that netmail has gotten into trouble with jam or squish.

    Have a nice night.
    Stas Mishchenkov.

    --- Have You daily sexual life? Hide it proper from Your wife! ;)
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
  • From Paul Hayton@3:770/100 to Stas Mishchenkov on Thu Dec 8 11:36:08 2022
    On 07 Dec 2022 at 09:29a, Stas Mishchenkov pondered and said...

    I don't know for what reason, but it seems to me that storing netmail in jam or squish is unnatural for it. I've noticed that this isn't the
    first time that netmail has gotten into trouble with jam or squish.

    Have a nice night.

    thanks, yes it's new to me so far had never had any issues until now.

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Tommi Koivula@2:221/6 to Nil Alexandrov on Fri Dec 9 09:27:02 2022
    Hi Nil.

    06 Dec 22 15:43:40, you wrote to me:

    I'm starting to see this error in my logs
    A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield
    occured! is the base corrupt? How best to resolve?

    The JAM base is definitely corrupted here, but the question is how
    you'vee ended up like this then?

    Good question indeed. I cannot remember how and when and which system I saw that happening. :(

    Are you guys running some software not compatible with 64bit?
    I remember seeing this with the original jamlib which was a part of jamnntpd for example, that only worked on 32-bit machines or you have
    to compile it with -m32 flag.

    JamNNTPd compiled 64bit is broken for sure. I can tell that JamNNTPd works fine in 32bit systems here like OS/2, Raspbian/32bit and Cygwin32. The latest compiled and installed in 64bit windows.

    I run SmapiNNTPd/64bit in Debian10/64bit with Golded/64bit and Husky/64bit. All compiled in that system, works fine.

    You could try to delete those empty messages
    with GoldED and then run "sqpack NETMAIL".

    That sounds like a workaround in absence of the database fix utility.

    The only problem running SQPACK is that it always renumbers the message base. Not acceptable with nntp clients. :(

    'Tommi

    ---
    * Origin: - rbb.fidonet.fi - Finland - (2:221/6)
  • From Tommi Koivula@2:221/6 to Stas Mishchenkov on Fri Dec 9 09:39:00 2022
    Hi Stas.

    07 Dec 22 09:29:52, you wrote to Paul Hayton:

    I don't know for what reason, but it seems to me that storing netmail
    in jam or squish is unnatural for it. I've noticed that this isn't
    the first time that netmail has gotten into trouble with jam or
    squish.

    I have never seen JAM related problems in netmail and I have used JAM netmail from day zero with GEcho/GoldED/Concord/Etc...

    'Tommi

    ---
    * Origin: - rbb.fidonet.fi - Finland - (2:221/6)
  • From Alan Ianson@1:153/757.2 to Tommi Koivula on Fri Dec 9 00:21:53 2022
    Hello Tommi,

    I don't know for what reason, but it seems to me that storing
    netmail in jam or squish is unnatural for it. I've noticed that
    this isn't the first time that netmail has gotten into trouble
    with jam or squish.

    I have never seen JAM related problems in netmail and I have used JAM netmail from day zero with GEcho/GoldED/Concord/Etc...

    Same here. I don't anymore but used squish netmail bases with Telegard and other software and I never have had any issues.

    Ttyl :-),
    Al

    ... Please write your complaint in this box [ ] - Legibly
    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757.2)
  • From Stas Mishchenkov@2:460/5858 to Tommi Koivula on Sun Dec 11 12:38:04 2022
    Hi Tommi!

    Friday December 09 2022 09:39, you wrote to me:

    I don't know for what reason, but it seems to me that storing netmail
    in jam or squish is unnatural for it. I've noticed that this isn't
    the first time that netmail has gotten into trouble with jam or
    squish.

    I have never seen JAM related problems in netmail and I have used JAM netmail from day zero with GEcho/GoldED/Concord/Etc...

    I can't say that I understand why this is happening. I just noticed that there are regular questions about netmail crashes in JAM or Squish in various echo conferences. And no one has ever complained about MSG.

    Have a nice night.
    Stas Mishchenkov.

    --- Have You daily sexual life? Hide it proper from Your wife! ;)
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
  • From Tommi Koivula@2:221/360 to Stas Mishchenkov on Sun Dec 11 12:03:58 2022
    On 11.12.2022 11:38, Stas Mishchenkov wrote:

    SM>> I don't know for what reason, but it seems to me that storing netmail
    SM>> in jam or squish is unnatural for it. I've noticed that this isn't
    SM>> the first time that netmail has gotten into trouble with jam or
    SM>> squish.

    TK> I have never seen JAM related problems in netmail and I have used JAM
    TK> netmail from day zero with GEcho/GoldED/Concord/Etc...

    I can't say that I understand why this is happening. I just noticed that there are regular questions about netmail crashes in JAM or Squish in
    various echo conferences. And no one has ever complained about MSG.

    Hmm, strange. Well this is husky echo, are those questions/complaints related to husky?

    'Tommi

    ---
    * Origin: rbb.fidonet.fi - Lake Ylo - Finland (2:221/360)
  • From Stas Mishchenkov@2:460/5858 to Tommi Koivula on Sun Dec 11 15:55:08 2022
    Hi Tommi!

    Sunday December 11 2022 12:03, you wrote to me:


    TK> I have never seen JAM related problems in netmail and I have used
    JAM
    TK> netmail from day zero with GEcho/GoldED/Concord/Etc...

    I can't say that I understand why this is happening. I just noticed that
    there are regular questions about netmail crashes in JAM or Squish in
    various echo conferences. And no one has ever complained about MSG.

    Hmm, strange. Well this is husky echo, are those questions/complaints related to husky?

    I'm not sure that only with the husky. However, since in Russian-speaking areas this is the most common tosser, then, highly likely, it is most often associated with it.

    Have a nice night.
    Stas Mishchenkov.

    --- Have You daily sexual life? Hide it proper from Your wife! ;)
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
  • From Carlos Navarro@2:341/234.12 to Tommi Koivula on Sun Dec 11 16:00:01 2022
    Hello, Tommi Koivula.
    On 9/12/22 9:27 you wrote:

    The only problem running SQPACK is that it always renumbers the
    message base. Not acceptable with nntp clients. :(

    Is that because sqpack doesn't have an option to not renumber, or is something about the Squish format itself?

    --
    Carlos
    --- Hotdoged/2.13.5/Android
    * Origin: cyberiada mobile point (2:341/234.12)
  • From Tommi Koivula@2:221/6 to Carlos Navarro on Sun Dec 11 17:02:24 2022
    Hi Carlos.

    11 Dec 22 16:00:00, you wrote to me:

    The only problem running SQPACK is that it always renumbers the
    message base. Not acceptable with nntp clients. :(

    Is that because sqpack doesn't have an option to not renumber,

    Yes.

    something about the Squish format itself?

    Nope, Fastecho for example can purge and pack without renumbering. Both JAM and Squish.

    'Tommi

    ---
    * Origin: - rbb.fidonet.fi - Finland - (2:221/6)
  • From Carlos Navarro@2:341/234.1 to Tommi Koivula on Thu Jan 26 14:50:51 2023
    11 Dec 2022 17:02, you wrote to me:

    The only problem running SQPACK is that it always renumbers the
    message base. Not acceptable with nntp clients. :(

    Is that because sqpack doesn't have an option to not renumber,

    Yes.

    Is sqpack no longer maintained?

    something about the Squish format itself?

    Nope, Fastecho for example can purge and pack without renumbering.
    Both JAM and Squish.

    Ok. I suppose you don't know of any other (standalone) tool that purges Squish bases...

    (Just curious - I currently use JAM and FMail so I don't need it.)

    Carlos

    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: cyberiada point (2:341/234.1)
  • From Tommi Koivula@2:221/6.600 to Carlos Navarro on Fri Jan 27 10:48:03 2023
    * Originally in FIDOSOFT.HUSKY
    * Crossposted in FMAIL_HELP

    Hi Carlos.

    Is sqpack no longer maintained?

    I think it is but nobody seems to be interested in fixing the renumbering issue. :(

    something about the Squish format itself?

    Nope, Fastecho for example can purge and pack without renumbering.
    Both JAM and Squish.

    Ok. I suppose you don't know of any other (standalone) tool that purges Squish bases...

    I believe not. :(

    (Just curious - I currently use JAM and FMail so I don't need it.)

    'ftools maint -D' seems to renumber JAM base here. How do you purge messages in JAM without renumbering?

    'Tommi

    --- FMail-lnx64 2.1.5.0-B20230106
    * Origin: -------------------> (2:221/6.600)
  • From Michael Dukelsky@2:5020/1042 to Tommi Koivula on Fri Jan 27 16:37:46 2023
    Hello Tommi,

    Friday January 27 2023, Tommi Koivula wrote to Carlos Navarro:

    Is sqpack no longer maintained?

    I think it is but nobody seems to be interested in fixing the
    renumbering issue. :(

    It is not a bug. It is a missing feature. That is why its priority is low.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From Tommi Koivula@2:221/360.8110 to Michael Dukelsky on Fri Jan 27 15:52:40 2023
    Hello, Michael Dukelsky.
    On 27/01/2023 16.37 you wrote:

    Hello Tommi,
    Friday January 27 2023, Tommi Koivula wrote to Carlos Navarro:
    Is sqpack no longer maintained?
    I think it is but nobody seems to be interested in fixing the
    renumbering issue. :(
    It is not a bug. It is a missing feature. That is why its priority is low.

    Nobody said it is a bug. :)


    --
    Tommi
    --- Hotdoged/2.13.5/Android
    * Origin: . (2:221/360.8110)
  • From Oli@2:280/464.47 to Tommi Koivula on Fri Jan 27 16:55:07 2023
    Tommi wrote (2023-01-27):

    (Just curious - I currently use JAM and FMail so I don't need it.)

    'ftools maint -D' seems to renumber JAM base here. How do you purge messages in JAM without renumbering?

    AFAIK JAM has no "unique message identifier" (UMSGID) like Squish. If you purge messages from the beginning, BaseMsgNum can be set:

    This field determines the lowest message number in the index file.
    The value for this field is one (1) when a message area is first
    created. By using this field, a message area can be packed (deleted
    messages are removed) without renumbering it. If BaseMsgNum contains
    500, the first index record points to message number 500.

    BaseMsgNum has to be taken into account when an application
    calculates the next available message number (for creating new
    messages) as well as the highest and lowest message number in a
    message area.

    If you delete messages in the middle you get holes without renumbering.

    Solution: use Squish (as in the software).

    ---
    * Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (2:280/464.47)
  • From Nil Alexandrov@1:16/101 to Oli on Fri Jan 27 11:08:46 2023
    Hello, Oli!

    Friday January 27 2023 16:55, from Oli -> Tommi Koivula

    AFAIK JAM has no "unique message identifier" (UMSGID) like Squish.

    You are right, JAM does not call it UMSGID but you can always have a unique message number by adding the basemsgnum value to otherwise 1-based message number. Well, unless you screw up the JAM database by running a broken purge tool which will reset basemsgnum back to 1.

    The Husky SMAPI library supports the UMSGID semantic for JAM message base as well. They could have done it more efficiently without reading out the whole index file for renumbering. My min UMSGID would be the basemsgnum. My max UMSGID would be the size of the index file divided by 8 plus the basemsgnum.

    If you delete messages in the middle you get holes without
    renumbering.

    Correct and this is expected behavior.

    A similar problem exists in the Usenet world and NNTP protocol (RFC3977). NNTP has to maintain unique message numbers, so the client can save lastread numbers locally, for example .newrc is the most popular file format for that.

    NNTP server will report the total number of active messages in the group (similar to "activemsgs" in JAM and "num_msgs" in Squish) and the low and high water mark. What would happen when the message in the middle is deleted? The number of active messages will be decremented but lowest and highest number will stay the same. Deleting from the beginning can be done my increasing the lowest number.

    Solution: use Squish (as in the software).

    Or write/fix the Jam purge tool which will be purging messages from the beginning and adjusting basemsgnum accordingly but keeping the holes in the middle which is by design there. Squish has introduced doubly linked lists, which is a different design solution for removing messages in the middle. Squish has a drawback though, the fixed array of 9 replies messages in the thread.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5
    * Origin: -=NIL BBS=- (1:16/101)
  • From Carlos Navarro@2:341/234.1 to Tommi Koivula on Fri Jan 27 20:47:38 2023
    'ftools maint -D' seems to renumber JAM base here.

    Same here. Wrong assumption.

    How do you purge messages in JAM without renumbering?

    I don't. Sorry... O:-)

    Carlos

    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: cyberiada point (2:341/234.1)
  • From Wilfred van Velzen@2:280/464 to Nil Alexandrov on Fri Jan 27 20:51:02 2023
    Hi Nil,

    On 2023-01-27 11:08:46, you wrote to Oli:

    Squish has a drawback though, the fixed array of 9 replies messages in
    the thread.

    And it removes the least significant bit of stored dates. So message dates only have even seconds, and thus sometimes messing with dupe checking on other systems, when forwarded messages have been stored in a squish message base before being forwarded to the links of a system. Btw: Hudson has the same problem.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Oli@2:280/464.47 to Wilfred van Velzen on Fri Jan 27 21:25:38 2023
    Wilfred wrote (2023-01-27):

    Hi Nil,

    On 2023-01-27 11:08:46, you wrote to Oli:

    Squish has a drawback though, the fixed array of 9 replies messages
    in the thread.

    And it removes the least significant bit of stored dates. So message dates only have even seconds, and thus sometimes messing with dupe checking on other systems, when forwarded messages have been stored in a squish message base before being forwarded to the links of a system. Btw: Hudson has the same problem.

    You keep repeating that myth. But it's in fact a problem with Husky's Franken-JAM-Squish-SMAPI and a JAM message base rescan / export. Squish bases do store the original header date string (__ftsc_date) which is used on rescans. That is part of the Squish format specification.

    The problem is that SMAPI uses the 2-second DOS date format, but there is no __ftsc_date for JAM bases that could be used. IIRC the correct datetime is stored in the JAM base by hpt / SMAPI, it just loses the least significant bit on export.

    Squish doesn't have this problem. I tested it with Squish and hpt, no dates were modified. Maybe there is some software that does it wrong, but in all the discussion nobody could name one.

    This is also not a problem on pass-through tossing.

    ---
    * Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (2:280/464.47)