On Friday 04 March 2016 00:31:09 Steve French wrote:
i.e. 32 bit systems should default to 32 bit time limits until the filesystem developers come along and verify that conversion from their on-disk format to 64 bit time works correctly. Then they set their real limits which may (or may not) be >y2038 compatible, and this means that filesystems that have not been converted to >y2038 compatible do not need any modifications to behave correctly on 32 bit systems...
We can set the limits in the superblock if you like, but I would not do it by changing the constants here:
Most file systems have arbitrary other maximum dates that they need to set (on 64-bit systems), e.g. 2028 (iso9660), 2040 (hfsplus), 2106 (ceph), 2107 (fat, cifs), 2262 (logfs), 2514 (ext4).
I am puzzled why 2107 would be the maximum date for cifs. My calculation comes to a maximum date of approximately the year 60,000AD for 64 bit DCE time (cifs.ko gets DCE time back in all time fields when using CIFS, SMB2 or SMB3 except for the oldest dialects of CIFS). DCE time is 100 nanoseconds since 1601 - see the definition of FILETIME in section 2.3.3 of https://msdn.microsoft.com/en-us/library/cc230324.aspx). And shouldn't this be the same for NTFS as they use a similar DCE time internally?
The value I was looking up in my table at http://kernelnewbies.org/y2038 indeed referred to the ancient SMB timestamps that use a 7-bit year number starting in 1980, just as fat has.
The year I have listed in the table for modern cifs and ntfs is 30328, which assumes that it's a signed 64-bit multiple of 100 nanoseconds, and that's what I see in cifs_NTtimeToUnix() as well. The documentation you point to describes it as unsigned, which matches your 60,000AD date, so before we add the limits, we should try to clarify which one was intended.
Arnd