TZUTC: -0700   
   MSGID: 52529.syncprog@1:103/705 2cff68b1   
   PID: Synchronet 3.21a-Linux master/d7c78e2c2 Aug 09 2025 GCC 12.2.0   
   TID: SBBSecho 3.29-Linux master/7a66d7f63 Aug 10 2025 GCC 12.2.0   
   BBSID: VERT   
   CHRS: ASCII 1   
   FORMAT: flowed   
   https://gitlab.synchro.net/main/sbbs/-/commit/3677011734466a2b9d1313a2   
   Modified Files:   
   	src/sbbs3/data.cpp download.cpp exec.cpp file.cpp ftpsrvr.c getmsg.cpp   
   getnode.cpp netmail.cpp readmsgs.cpp sbbsdefs.h str.cpp un_rep.cpp upload.cpp   
   userdat.c userdat.h useredit.cpp userfields.h writemsg.cpp xtrn_sec.cpp   
   Log Message:   
   Address concurrency issues with user daily statistics (and free credit) fields   
      
   Add/use a new user field: 'reset' which stores the last date/time that the   
   user record's daily fields were zeroed. Use this new 'reset' date rather than   
   the last logon or logoff date of the user to determine if the daily fields   
   need to be zeored or not. The previuos method (checking against the user's   
   logon or logoff date)  was rife with problems that could lead to these 'daily'   
   (*today) fields being wildly inaccurate - especially when the user only ever   
   used non-terminal servers/protocols (e.g. the mail server).   
      
   The occasional daily stat reset check while logged into the terminal server   
   (via node_sync()) still exists since its expected that users may be logged-in   
   across midnight, but includes a fix for the occasion that the user is logged-in   
   across multiple midnights. Previously, in this scenario, their "in memory"   
   daily stats would *not* be reset on subsequent days (for the same login   
   session). Also added a debug-level log message when the new day is detected.   
   Although we still set the sys_state flag to indicate a new date was detected,   
   we don't do anything with that flag (since the user reset timestamp is what we   
   actually want to use for this purpose) - not sure if any JS script might want   
   to know, so it's still set even though it's not reset until log-off, which   
   could be after a multiple-day login session.   
      
   Other servers/services don't really have a multiple-day user session solution   
   just yet, but at least when there is user activity that is counted as a daily   
   stat, then the 'new day' will be detected and the stats reset (both on disk   
   and in memory). This change was why the adjustuserval() function signature   
   changed, resulting in most of the changes in this commit (to all the call-sites   
   of adjustuserval()).   
      
   There were some remaining legacy ushort typecasts too, so deleted those.   
      
   This investigation and subsequent overhaul was triggered by issue #961 which I   
   only kind of / sort of fixed with the commit that claimed to fix it. This is   
   the real fix.   
   --- SBBSecho 3.29-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 103/705 105/81 106/201 124/5016 128/187 153/757 7715 154/10   
   SEEN-BY: 154/30 110 203/0 218/700 221/0 226/30 227/114 229/110 114   
   SEEN-BY: 229/206 317 400 426 428 470 700 705 240/1120 5832 263/1 266/512   
   SEEN-BY: 280/464 5003 5006 291/111 292/8125 301/1 320/219 322/757   
   SEEN-BY: 341/66 234 342/200 396/45 423/120 460/58 256 1124 467/888   
   SEEN-BY: 633/280 712/848 770/1 902/26 5020/400 8912 5054/30 5075/35   
   PATH: 103/705 280/464 460/58 229/426