Hi Chris, Thanks for your reply about the merits of including support for reading utmp-formatted files. An important technical correction follows below for any observer reading this thread (mea culpa):
On Sun, Feb 09, 2025 at 07:34:07PM +0100, Chris Hofstaedtler wrote: > On Sun, Feb 09, 2025 at 08:46:39AM +0000, Andrew Bower wrote: > > On Sun, Feb 09, 2025 at 01:01:08AM +0100, Chris Hofstaedtler wrote: > > > On Sat, Feb 08, 2025 at 12:47:05PM +0000, Andrew Bower wrote: [..] > > utmp would work past 2038 except on i386 - and for > > 32-bit architectures that is thanks to the hard work you all did, thank > > you! The big issue with utmp is the certainty of corruption when > > accessed by both t64-capable and non t64-capable software. > > TTBOMK the utmp format did not change on any architecture, so it is > has the year 2038 limitation. Sorry, I was simply wrong here, so let me correct the record from my technical error: when I went in to look at the header (potentially with a view to contributing an importer) I realised I had not actually checked it and was relying on false memory of what I had inferred it to be from skimming discussions about why it _couldn't_ be changed, thinking it had indeed been changed (or rather, how it might have already changed by virtue of relying on time_t). The limitation does apply, as you say. (This was of course a side issue anyway as I was not disputing the merit of changing from utmp, just access to tooling.) > > This is just using a private facility and so no one else is writing to > > the file - it will be y2038-safe if the host is, they are just using the > > system tool as a reader for that file because it is generally assumed to > > be present. In fact their risk is upon upgrading the OS from > > armhf/armel/hppa/m68k/powerpc/sh4 when this file _will_get_corrupted_ - > > How so? As discussed above, this is indeed incorrect.
