Hi Darrick On Wed, Mar 09, 2022 at 08:00:19AM -0800, Darrick J. Wong wrote: > On Wed, Mar 09, 2022 at 05:53:03PM +1030, Jonathan Woithe wrote: > > Since the kernel on PC-2 is way earlier than 5.10 and its xfs filesystems > > predate bigtime, I would have expected the times to be clamped between > > 1901 and 2038. However, it seems that the system somehow manages to store > > the out-of-bound years. Doing so has an interesting effect on the timezone > > offset for the pre-1901 years, but for years beyond 2038 there is no > > directly observable problem. ... > > : > > This isn't what I expected. Given an old userspace with an old kernel and > > old xfs filesystem, dates outside the 1901-2038 range should not be > > possible. Given the apparent corruption of the timezone field when a year > > before 1901 is set, one naive thought is that the apparent success of these > > extended years on PC-2 (the old system) is due to a lack of bounds checking > > on the time value and (presumedly) some overflow within on-disc structures > > as a result. This would have been noticed way before now though. > > > > I am therefore curious about the reason for the above behaviour. What > > subtlety am I missing? > > Older kernels (pre-5.4 I think?) permitted userspace to store arbitrary > 64-bit timestamps in the in-memory inode. The fs would truncate (== rip > off the upper bits) them when writing them to disk, and then you'd get > the shattered remnants the next time the inode got reloaded from disk. > > Nowadays, filesystems advertise the timestamp range they support, and > the VFS clamps the in-memory timestamp to that range. Thanks so much for taking the time to respond. That all makes sense and is useful information to keep in mind. Regards jonathan
