Re: [Y2038] [PATCH] vfs: Add support to check max and min inode times

[Arnd Bergmann <arnd@arndb.de>]

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