Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview]

[Garrett D'Amore]

Alan Coopersmith wrote:
> Joerg Schilling wrote:
>   
>> "Garrett D'Amore" <gdamore at sun.com> wrote:
>>
>>     
>>>>> stat64(2) already exists -- you get it with largefile compiles. However, 
>>>>>   I don't think the time fields are 64 bit.
>>>>>     
>>>>>           
>>>> They are not. This is the problem.
>>>>
>>>> Jörg
>>>>         
>>     
>>> I think its time we invented a new version of stat, utimes, etc. that 
>>> used 64-bit time_t's, even on 32-bit kernels.  Some new compilation 
>>> flags (-DTIME64 ?)  could use #pragma's to rename the symbols for "new" 
>>> programs, which could be then used for compiling programs in ON.
>>>       
>> If you like this to be independent of largefile compilation, you would need
>> to introduce two new interfaces for stat(2).
>>     
>
> And that's my concern - how many types are we going to retrofit in the
> 32-bit ABI, and what is the resulting combinatorial explosion of different
> type-combinations going to look like?
>   

The matrix of supported options can be "sparse".   We don't have to 
support small files with 64-bit times, for example.

It does mean that the times used for system calls involving time_t need 
to be updated.  There probably aren't that many.  Driver-specific ioctls 
with time_t embedded in them can be converted on an as needed basis 
(hopefully there aren't that many driver-specific ioctls passing around 
time_ts.)

    -- Garrett