Any explanation on how this happens?
Access: 2023-12-14 07:57:28.376736001 +1300 Modify: 2023-12-14 07:50:20.783207177 +1300 Change: 2023-12-14 07:51:57.413989824 +1300 Birth: 2023-12-14 07:51:57.413989824 +1300
Just as a matter of curiosity
FWIW, the stat structure in Linux does not include birth time [1]. It only gives you:
atime: The time of last access.mtime: The time of last modification.ctime: The time of the last change to the inode.
I assume the
statcommand is using a filesystem-specific method to get the birth time.Anyway, I don’t think any of these stats is guaranteed to be consistent with the rest (or even correct). For example, it is common to disable
atimetracking to improve I/O performance.Assuming the data is accurate, I think the other comment about the file being a copy is the best explanation.
The
statcommand is using statx, which gives you a slightly different struct. statx is the cool new Linux-only system call for stat-ing. Not every filesystem will support the new btime field. (And, as you correctly say, many of those time fields are wrong, anyway)Ooo neat. I was not aware of this syscall. TIL!
The struct returned by
statdoesn’t, butstatxcontains creation time as well as well. I believe ext4 is already tracking the creation time even ifstatcan’t provide it.The
statcommand on modern distros should get you this additional metadata, unless you use an FS that doesn’t track or expose it, of course.
I don’t know what exact situation could have happened here but I imagine a copy could have also copied the metadata into a new file. So it creates a new file as the destination (setting the birth date), then as part of copying the file it copied the access and modify times.
There are ways this can happen even without the technicalities of date tracking on the Linux file system. Take, for example, Microsoft’s decision to store local time in the system clock. If you dual boot, and don’t configure either Linux or Windows to be consistent with the other, your clock will be off by one or more hours, unless you happen to live at UTC+00:00. Every modern computer users NTP to automatically correct itself, but it’s not uncommon to see tons of files with weird timestamps after booting Windows.
Even without dual booting, it’s possible your computer’s clock has drifted into the future when it was off, and got corrected later. That would explain seconds or minutes of differences.
