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
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.