Re: Files dated before 1970

[Matthew Wilcox <willy@infradead.org>]

On Sat, Jun 20, 2020 at 10:59:48AM +0200, Arnd Bergmann wrote:
> On Sat, Jun 20, 2020 at 4:16 AM Matthew Wilcox <willy@infradead.org> wrote:
> > le32_to_cpu() returns a u32.  Before your patch, the u32 was assigned
> > to an s32, so a file with a date stamp of 1968 would show up that way.
> > After your patch, the u32 is zero-extended to an s64, so a file from
> > 1968 now appears to be from 2104.
> 
> In the case of JFS, I think the change of behavior on 32-bit kernels was
> intended because it makes them do the same thing as 64-bit kernels.

Oh!  I hadn't realised that 64-bit kernels were already using a 64-bit
signed tv_sec.  That makes a world of difference.

> For JFS and the others that already used an unsigned interpretation
> on 64 bit kernels, the current code seems to be the least broken
> of the three alternatives we had:
> 
> a) as implemented in v4.18, change 32-bit kernels to behave the
>    way that 64-bit kernels always have behaved, given that 99% of
>    our users are on 64-bit kernels by now.
> 
> b) keep 32-bit and 64-bit kernels use a different interpretation,
>    staying compatible with older kernels but incompatible between
>    machines or between running the same user space on the
>    same machine in either native 32-bit mode or compat mode
>     a 64-bit kernel
> 
> c) change the 99% of users that have a 64-bit kernel to overflowing
>     the timestamps in y2038 because that was what the kernel
>     file system driver originally implemented on 32-bit machines
>     that no concept of post-y2038 time.

Yes, I agree, knowing more of the facts, this was the right decision to
make at the time, and I wouldn't change it now.  Thanks!