Hi all Today I was running some file timestamping tests to get a feel for the bigtime XFS option and to confirm that it was doing what I expected. Everything made sense until a certain point. There are two systems: * PC-1: Slackware64 15.0, xfsprogs 5.13.0, 5.15.27 kernel * PC-2: Slackware64 14.2, xfsprogs 4.3.0, 4.4.19 kernel On PC-1 with an xfs created many years ago, xfs_info reports bigtime=0 (as expected). Two tests were run: * > touch -d '1800/01/01 02:23:45.67' foobar > ls --full-time foobar -rw-r--r-- 1 jwoithe users 0 1901-12-14 06:15:52.000000000 +0930 foobar * > touch -d '2100/01/01 02:23:45.67' foobar > ls --full-time foobar -rw-r--r-- 1 jwoithe users 0 2038-01-19 13:44:07.000000000 +1030 foobar Both results are entirely as expected: the times are clamped to the minimum and maximum values. The +0930 timezone in the 1901 date is due to there being no daylight saving in operation in 1901. A newly created xfs is also on PC-1 where bigtime was requested during mkfs.xfs. Bigtime is confirmed set according to xfs_info. Three tests were run: * > touch -d '1800/01/01 02:23:45.67' foobar > ls --full-time foobar -rw-r--r-- 1 radar users 0 1901-12-14 06:15:52.000000000 +0930 foobar * > touch -d '2100/01/01 02:23:45.67' foobar > ls --full-time foobar -rw-r--r-- 1 radar users 0 2100-01-01 02:23:45.670000000 +1030 foobar * > touch -d '2800/01/01 02:23:45.67' foobar > ls --full-time foobar -rw-r--r-- 1 radar users 0 2486-07-03 05:50:24.000000000 +0930 foobar Again, everything is as expected. Bigtime expands the maximum time out to 2486 as advertised. The +0930 timezone in the last result is due to there being no daylight saving in July. Turning to PC-2, things became confusing. This older enviroment also has an xfs created many years ago. Two tests were run: * > touch -d '1800/01/01 02:23:45.67' foobar > ls --full-time foobar -rw-r--r-- 1 jwoithe users 0 1800-01-01 02:23:45.670000000 +0914 foobar * > touch -d '2100/01/01 02:23:45.67' foobar > ls --full-time foobar -rw-r--r-- 1 jwoithe users 0 2100-01-01 02:23:45.670000000 +1030 foobar 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. Incidently, running stat foobar happily reports the extended date in this case too: Access: 2100-01-01 02:23:45.670000000 +1030 Modify: 2100-01-01 02:23:45.670000000 +1030 For a giggle I tried > touch -d '21000/01/01 02:23:45.67' foobar and the system still managed to store the 5-digit year: -rw-r--r-- 1 jwoithe users 0 21000-01-01 02:23:45.670000000 +1030 foobar 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? While this may be a well known quirk, it is rather difficult to search for online. I've tried a few things but they haven't turned up any relevant matches. Apologies if this is an FAQ that I can't locate. Regards jonathan
