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 _______________________________________________ Y2038 mailing list [email protected] https://lists.linaro.org/mailman/listinfo/y2038
