* Originally in fidosoft.husky
* Crossposted in fidotest

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

 WV> * Originally in FIDOTEST
 WV> * Crossposted in FIDOSOFT.HUSKY

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

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

 NB>> Forwarded messages are untouched.

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

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

 WV> I think this needs to be taken up or explained by one of the husky
 WV> maintainers (hence the crosspost). I have no intention learning/fixing
 WV> 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.
---