Fwd: 64-bit time_t transition for 32-bit archs: a proposal

Forwarding this discussion from debian-devel about 64-bit time_t migration
to inn-workers since this is a better place to discuss the details.

To: [email protected]
Subject: Re: 64-bit time_t transition for 32-bit archs: a proposal
From: Olaf Titz <[email protected]>
Date: Mon, 26 Jun 2023 20:08:50 +0200

> > Oh, wait!  No, I'm wrong, CNFS actually does something smart and encodes
> > the header in ASCII when writing it to disk.
> >
> > Okay, phew, this isn't going to be nearly as bad as I had thought.
>
> Good news. It would be great if you could add relevant info to the wiki page:
> https://wiki.debian.org/ReleaseGoals/64bit-time#Known_Issues

That page now says
< The CNFS storage format does not have problems with its disk format,
< but the less-used timecaf storage format might (yet to be confirmed).

Yes, timecaf does have a problem, two actually.

1. The CF file header contains a field time_t LastCleaned. Changing
sizeof(time_t) will change sizeof(CAFHEADER) and make existing CF file
unreadable with newly compiled code.

AFAICT that field is only written once and never read, so it could be
patched out, but that requires some care.

2. The CF files use file names like timecaf-nn/bb/aacc.CF where nn is
the storage class and aabbccxx the time of arrival, changing the file
name in 256-second intervals. The code using %02x format strings to
determine the file name, and everything else checking them for
validity, will have to be changed appropriately.

Olaf
-- 
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers