REPLY: 2:280/464.47@fidonet 5dc6c668   
   MSGID: 1:320/219@fidonet 5dc75662   
   CHRS: CP437 2   
   TZUTC: -0500   
   TID: MBSE-FIDO 1.0.7.13 (GNU/Linux-x86_64)   
   Hello Oli!   
      
   09 Nov 19 14:32, you wrote to me:   
      
    AL>> Binkp: M_GOT "SIOREG.ZIP 21096 18446744073453975120" +   
      
    Ol> That is an interesting unix timestamp, which doesn't fit into a 64-bit   
    Ol> signed integer.   
      
   I noticed that too.  It definitely looks like someone is treating it as    
   unsigned instead of signed.   
      
    Ol> 18446744073453975120 / 2 -> November 16, 219250464   
      
    Ol> Even if this were in nanoseconds it would be a date far in the future:   
    Ol> July 21, 2554   
      
    AL>> I need to add logging of the sent M_FILE messages to confirm that   
    AL>> mbcico is sending a 32-bit value in the M_FILE.  You can see that   
    AL>> the remote (binkd 1.1a-99/Linux) is sending a 64-bit value for   
    AL>> the Unixtime in the M_GOT frame.   
      
   I'll have to tcpdump the incoming packets to be sure, but I've never seen that    
   happen with any other node.   
      
    Ol> Looks like a bug to me that needs fixing. Are you sure that binkd   
    Ol> sends this number?   
      
   Definitely a bug somewhere; I just need to establish for sure whether it's in    
   mbcico or binkd.   
      
    Ol>>> Does it break compatibility with any mailer? You didn't mention   
    Ol>>> any specific example.   
      
    AL>> mbcico (the mailer included with MBSE BBS) rejects the M_GOT with   
    AL>> the 64-bit value and ends up trying to send the file again in the   
    AL>> next session.  I suspect that ifcico (which mbcico was based on)   
    AL>> will do the same, although I haven't tested it yet.   
      
    Ol> Every mailer should reject that M_GOT, the value doesn't make any   
    Ol> sense.   
      
   Incidentally, I discovered that the timestamp of that file on disk was showing    
   as November 25, 1961, so it should be a negative value.  Converting the    
   decimal to hex yields FFFF FFFF F0C4 3650, which in 2's complement notation is    
   -255576496.  A quick Unix time conversion results in Sat 25 Nov 1961 10:31:44    
   PM UTC.  Therefore, it appears that the value is a correct 64-bit Unixtime for    
   the file timestamp as it was on disk.   
      
   Andrew   
      
   --- GoldED+/LNX 1.1.5-b20180707   
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)   
   SEEN-BY: 1/19 123 16/0 90/1 103/705 120/544 123/130 131 132/174 142/926   
   SEEN-BY: 154/10 203/0 221/0 1 6 242 360 227/114 229/101 200 354 426   
   SEEN-BY: 229/1014 230/0 240/5832 249/307 317 261/38 280/464 5003 5555   
   SEEN-BY: 292/854 310/31 320/119 219 322/0 342/200 396/45 423/81 120   
   SEEN-BY: 640/1384 712/848 770/1 2452/250   
   PATH: 320/219 221/1 280/464 229/426