* 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)

* 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)

* 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)

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)

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)

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)