• Re: Uneven seconds test

    From Wilfred van Velzen@2:280/464 to Nicholas Boel on Thursday, December 22, 2016 18:34:01
    * Originally in FIDOTEST
    * Crossposted in FIDOSOFT.HUSKY

    Hi,

    On 2016-12-22 11:26:32, Nicholas Boel wrote to Wilfred van Velzen:
    about: "Uneven seconds test":

    Pity. We still like to know if forwarded messages by hpt also have
    uneven seconds changed to even.

    Forwarded messages are untouched.

    Or if it's just a storage "problem" on hpt. In that case only
    re-scanned messages will be a problem for the world outside of the hpt
    system...

    It looks to be this way as far as I can tell. Which makes me wonder, both toss.c and toss.h make use of "int strip" in the line that stores messages to the areas, whereas the forward messages to links line (or any others
    for
    that matter) does not. But seeing as though my programming skills are even far from mediocre, I'm not going to bother attempting anything that will most likely cause a lot of headaches for myself. :)

    I think this needs to be taken up or explained by one of the husky maintainers (hence the crosspost). I have no intention learning/fixing software I don't use
    myself. ;)

    Bye, Wilfred.


    --- FMail-W32 1.73.10.56-B20161219
    * Origin: Native IPv6 connectable node (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Thursday, December 22, 2016 18:46:07
    * Originally in FIDOTEST
    * Crossposted in FIDOSOFT.HUSKY

    Hi,

    On 2016-12-22 19:33:58, Tommi Koivula wrote to Wilfred van Velzen:
    about: "Uneven seconds test":

    @PATH: 280/464 240/1661 221/6 0

    And this route is ok too.

    221/6 and 221/0 are HPT!

    Nic found out only stored messages are changed by hpt...

    Bye, Wilfred.


    --- FMail-W32 1.73.10.56-B20161219
    * Origin: Native IPv6 connectable node (2:280/464)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Thursday, December 22, 2016 15:33:46
    * Originally in fidosoft.husky
    * Crossposted in fidotest

    22 Dec 16 18:34, you wrote to Nicholas Boel:

    * Originally in FIDOTEST
    * Crossposted in FIDOSOFT.HUSKY

    i've included the other area, too...

    Pity. We still like to know if forwarded messages by hpt also have
    uneven seconds changed to even.

    Forwarded messages are untouched.

    Or if it's just a storage "problem" on hpt. In that case only
    re-scanned messages will be a problem for the world outside of the
    hpt system...

    It looks to be this way as far as I can tell. Which makes me wonder,
    both toss.c and toss.h make use of "int strip" in the line that
    stores messages to the areas, whereas the forward messages to links
    line (or any others for that matter) does not. But seeing as though
    my programming skills are even far from mediocre, I'm not going to
    bother attempting anything that will most likely cause a lot of
    headaches for myself. :)

    I think this needs to be taken up or explained by one of the husky maintainers (hence the crosspost). I have no intention learning/fixing software I don't use myself. ;)

    what i recall is that some software uses the DOS time stamp that the file system uses... that time stamp has 2 second resolution... DOS FAT12, FAT16 and FAT32 time stamps are packed 16-bit values... only bits 0 to 4 are used to count the seconds. you can't count to 59 with only 5 bits unless you cut the resolution in half... thus you get 2 second resolution...

    in fact, copying a file from NTFS that has a time stamp with an odd number of seconds will see that time stamp altered to an even number of seconds... generally one higher than the odd second that was in place... i'm not sure if this will include minute roll over if the time stamp was 59 seconds... it should but i've not dug into the m$ documentation concerning it...

    anyway some software uses the file system time stamp format for the messages' time stamp(s)... the reason why they use the file system time stamp format is mainly because they already have it and there's no real reason try to grab another one... other software may use 1 (one) second or greater clock time granularity if their message base time stamp format supports it... back in the
    day, most just used the file system time stamp as it was an easy routine to grab a stamp from...

    FTS-0001 does not specify if the datetime stamp in a message is to be the file system time stamp or the clock time stamp... it only says that stored and packed messages' datetime is to be a string 20 bytes long (19 bytes plus a terminating null)... the FIDO format has seconds whereas the seadog format does
    not... the datetime is also noted in FTS-0001 as "message body was last edited"... the only other place that FTS-0001 talks about time stamps is in the
    transfer protocols and there they are in DOS file system format which has 2sec granularity...

    as far as processing messages in fidonet, from PKT to PKT, there should be no modification of the time stamp... it is a simple buffer copying process... no conversion from the string format it is to a numerical format which has to be converted back to a string... certainly not when copying the message from the original PKT to other PKTs destined to other systems... you just copy the buffer to the other PKTs (likely QQQs at this point)...

    the time stamp may be converted for local storage but that depends on the message base format the message is being stored in... rescanning messages should not result in different time stamps since the stored time should be the same as the original time unless the local format is using the DOS file system format... if that's the case then the time stamp may generally be up to 2 seconds greater than the original time... this because when converting to the DOS file system format, you always round up to the next even second... that is documented by m$ on the NTFS thing above... so you are asking why do that with a message time stamp? because the coder may be using the file system time routines and not simple clock routines...


    i'll stop there... call it 2 cents with inflation ;)


    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... The thoughtless are rarely wordless.
    ---
    * Origin: (1:3634/12.73)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Friday, December 23, 2016 11:58:31
    Hi,

    On 2016-12-22 15:33:46, mark lewis wrote to Wilfred van Velzen:
    about: "Uneven seconds test":

    * Originally in FIDOTEST
    * Crossposted in FIDOSOFT.HUSKY

    i've included the other area, too...

    I didn't, anymore. ;)

    what i recall is that some software uses the DOS time stamp that the
    file system uses... that time stamp has 2 second resolution... DOS
    FAT12, FAT16 and FAT32 time stamps are packed 16-bit values... only
    bits 0 to 4 are used to count the seconds. you can't count to 59 with
    only 5 bits unless you cut the resolution in half... thus you get 2
    second resolution...

    Yes, I know about that. And hpt probably uses something like that for the internal date/time representattion before it stores it in the JAM messagebase. Otherwise I can't explain why that even happens in Nick's native linux environment...

    Bye, Wilfred.


    --- FMail-W32 1.73.10.56-B20161219
    * Origin: Native IPv6 connectable node (2:280/464)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Friday, December 23, 2016 07:22:02

    On 2016 Dec 23 11:58:30, you wrote to me:

    what i recall is that some software uses the DOS time stamp that the
    file system uses... that time stamp has 2 second resolution... DOS
    FAT12, FAT16 and FAT32 time stamps are packed 16-bit values... only
    bits 0 to 4 are used to count the seconds. you can't count to 59 with
    only 5 bits unless you cut the resolution in half... thus you get 2
    second resolution...

    Yes, I know about that. And hpt probably uses something like that for
    the internal date/time representattion before it stores it in the JAM messagebase. Otherwise I can't explain why that even happens in Nick's native linux environment...

    remember there are two message format libraries... one based on SQUish and the other also based on SQUish but with JAM and MSG added in... MAPI and SMAPI?? and then there's the original JAMLIB released by joho and crew...

    but the origin based on SQU is why some utils of HPT still show their SQU roots
    (eg: sqpack)... SQUish uses that old DOS file system time format with 2sec granularity... i suspect they're using the same routine with JAM instead of branching off for the date at the same place they do for MSG which we know uses
    a string format... the JAM one is just a plain unix time stamp and needs no manipulation...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... I'm being held prisoner in a chocolate factory. Don't send help.
    ---
    * Origin: (1:3634/12.73)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Friday, December 23, 2016 14:28:58
    Hi,

    On 2016-12-23 07:22:02, mark lewis wrote to Wilfred van Velzen:
    about: "Uneven seconds test":

    Yes, I know about that. And hpt probably uses something like that for
    the internal date/time representattion before it stores it in the JAM
    messagebase. Otherwise I can't explain why that even happens in Nick's
    native linux environment...

    remember there are two message format libraries... one based on SQUish and the other also based on SQUish but with JAM and MSG added in... MAPI and SMAPI?? and then there's the original JAMLIB released by joho and crew...

    but the origin based on SQU is why some utils of HPT still show their SQU roots (eg: sqpack)... SQUish uses that old DOS file system time format
    with
    2sec granularity... i suspect they're using the same routine with JAM instead of branching off for the date at the same place they do for MSG which we know uses a string format... the JAM one is just a plain unix
    time
    stamp and needs no manipulation...

    That sounds likely... And I don't want to check the source. ;)

    Bye, Wilfred.


    --- FMail-W32 1.73.10.56-B20161219
    * Origin: Native IPv6 connectable node (2:280/464)