This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Y2038] Fifth draft of the Y2038 design document
On Mon, Feb 27, 2017 at 10:19 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Mon, 27 Feb 2017, Arnd Bergmann wrote:
>
>> Good idea, thanks! We currently do the checking separately from
>> the copying, but doing the two together is a good cleanup and also
>> helps the places that currently lack a range check (typically in
>> drivers). We have three different checks on a timespec at the moment
>> (no check on tv_sec range, tv_sec must be positive, or tv_sec must
>> be within the 400 year range of 64-bit nanoseconds), but the
>> check for the nanoseconds is always the same.
>
> I'd expect two different versions of the nanoseconds check (one for utimes
> functions that allows UTIME_OMIT and UTIME_NOW, one for other uses that
> doesn't).
Ok, good to know, I had forgotten about those.
> (utimes functions are also a case where a negative tv_sec is
> perfectly reasonable, but EINVAL is needed if the value is outside a
> filesystem-specific range - "A new file timestamp would be a value whose
> tv_sec component is not a value supported by the file system.".)
Right, this is being worked on already, we are actually adding file system
specific range checking here, based on the capabilities of the on-disk
format, we might have different minimum and maximum values, e.g.
1902..2038 (ext3), 1970..2106 (afs), 1980..2099 (fat), 1902..2446 (ext4)
or TIME_T_MIN..TIME_T_MAX (btrfs).
This was never handled correctly in Linux, and we usually just overflow the
times today, resulting in more or less much random times when reading
the data back.
Arnd