Re: [PATCH 3/5] login: Add 64-bit time support

["Maciej W. Rozycki via Libc-alpha" <libc-alpha@sourceware.org>]

On Thu, 30 Jul 2020, Adhemerval Zanella via Libc-alpha wrote:

> >> New symbols for getutent, getutent_r, getutid, getutid_r, getutline,
> >> getutline_r, getutmp, getutmpx, getutxent, getutxid. getutxline,
> >> pututline, pututxline, updwtmp, updwtmpx, and login are added to
> >> all architecture but s390-32 (which already added 64-bit time support
> >> on 32-bit ABI on glibc 2.9).
> > 
> > I thought those structures appeared in external files (/var/run/utmp, 
> > /var/log/wtmp, /var/log/lastlog), which means changing them is problematic 
> > even with symbol versioning.  Do the files keep their existing formats 
> > with the new versions of the functions translating to and from the 64-bit 
> > format when reading / writing those files?  Do they get new formats with 
> > the old versions of the functions instead being the ones that translate 
> > (if so, what is the process distributions are expected to use to convert 
> > existing files on upgrade / enable old wtmp files in the old format to 
> > continue to be read by new code)?  I think a detailed description of the 
> > overall strategy for maintaining compatibility with existing data in files 
> > is needed, both in the patch / patch series description and in the NEWS 
> > file describing anything required to be done on upgrade to avoid losing or 
> > corrupting data.
> > 
> 
> The strategy I used was the same done by s390-32 some time ago, where
> the var/run/utmp, /var/log/wtmp, /var/log/lastlog would use the new
> 64-bit time regardless and the 32-bit compat symbols convert the 32-bit
> entries to the internal 64-bit ones.  Afaik there is not conversion tool 
> to handle that, so the system administration was supposed to reset such 
> files in a glibc upgrade.

 Hmm, there could be many copies of glibc used at once on a single system 
(e.g. for different ABIs) all accessing the same login records on behalf 
of different programs, and the intended process has been agreed upon it 
would seem so that administrators could make the switch as they would see 
fit rather than being forced to do so at the time of a glibc upgrade: 
<https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#utmp_types_and_APIs>.

  Maciej