* 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.
---
 * Origin:  (1:3634/12.73)