From: usenet.16@scottsonline.org.uk.invalid   
      
   On 04/12/2025 14:09, Paul wrote:   
   > On Thu, 12/4/2025 6:42 AM, Mike Scott wrote:   
   >> Hmmm.   
   >>   
   >> Checking over things, I found some old files with dates in the future. One   
   directory lists as:   
   >>   
   >> CD> ls -li   
   >> total 36   
   >> 3671727 -rw-rw-r-- 1 mike mike  1230 Oct 16  2018 cd1.k3b   
   >> 3671728 -rw-rw-r-- 1 mike mike  1160 Oct 16  2018 cd1.k3b.files   
   >> 3671729 -rw-r--r-- 1 mike mike   137 Oct 16  2018 k3b2list.sh   
   >> 3671730 -rw-r--r-- 1 mike mike 17873 Feb  7  2106 maindata.xml   
   >> 3671731 -rw-r--r-- 1 mike mike    17 Feb  7  2106 mimetype   
   >>   
   >>   
   >> Note the future dates for the last two. This stuff has been left around   
   since 2018, unmodified (by me, at least). The contents look reasonable, so   
   it's just the metadata messed up - they seem to be the only two files affected.   
   >>   
   >> The data was on a freebsd machine until a few weeks ago, when the whole lot   
   was rsync'd from spinning rust to the present SSD on a mint server.   
   >>   
   >> A bit worrying: freebsd failure? rsync failure? SSD failure? linux failure?   
   Gremlins?   
   >>   
   >> But how can anyone possibly realistically detect this sort of thing? With   
   an unknown cause?   
   >>   
   >>   
   >   
   > https://github.com/antrea-io/antrea/issues/1417   
   >   
   >     "https://tools.ietf.org/html/rfc7011#section-6.1.7 does state:   
   >   
   >      The dateTimeSeconds data type is an unsigned 32-bit integer in   
   >      network byte order containing the number of seconds since the UNIX   
   >      epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1].   
   >      dateTimeSeconds is encoded identically to the IPFIX Message Header   
   >      Export Time field. It can represent dates between 1 January 1970 and   
   >      7 February 2106 without wraparound; see Section 5.2 for wraparound   
   considerations."   
   >      ^^^^^^^^^^^^^^^   
   >   
   > That appears to be a magic number and not a random corruption.   
   > That would be a software problem of some sort.   
      
   Thanks for pointing that out; I'd missed the significance.   
      
   Nevertheless, /something/ changed the dates somewhen - they should all   
   be similar. I've checked old dump files around from freebsd, but restore   
   (on mint) sets the extracted file dates to the current time, which isn't   
   helpful (and wrong behaviour?!)   
      
   My random guess would be rsync. But that's just because the wind's in   
   the south-west :-}   
      
   >   
   >     Paul   
      
      
   --   
   Mike Scott   
   Harlow, England   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)