On Thu, 2017-08-17 at 17:31 +0200, Julian Andres Klode wrote:
> OK, so I'd say that maybe the optimal solution then is to store it as:
>
> \xaa\xe5\xe9\x42\x00\x00\x00\x01
>
> That is, swap the upper and lower 4 bytes when loading/writing. This
> way, files writing by old versions behave as before; and for old code,
> databases generated by new code will look the same for small files - that
> is, you can also rollback your apt-ftparchive version without anything
> breaking.
I like that.
> > - CurStat.mtime = htonl(St.st_mtime);
> > + CurStat.mtime = htobe32(St.st_mtime);
>
> On the other hand, we should really migrate mtime to 64-bit
> as well.
>
> But: The question is do we want to just change mtime to a 64-bit
> field, or do we just want to append a new integer to it, and manually
> reconstruct the 64-bit? Then we can avoid changing the file format
> and old versions can still read it (until 2038).
Enlarging the datastructure will cause current versions of apt-ftparchive to
refuse to read the cache entry, even if it's otherwise binary compatible: see
the current definition of CacheDB::GetCurStat():
if (Data.size == 0)
{
// nothing needs to be done, we just have not data for this deb
}
// check if the record is written in the old format (32bit filesize)
else if(Data.size == sizeof(CurStatOldFormat))
{
GetCurStatCompatOldFormat();
}
else if(Data.size == sizeof(CurStat))
{
GetCurStatCompatNewFormat();
} else {
return _error->Error("Cache record size mismatch (%ul)", Data.size);
}
(From https://anonscm.debian.org/git/apt/apt.git/tree/ftparchive/cachedb.cc)
The size of the record read from the Berkeley DB is being used to implicitly
version the CurStat record being read.
If we're going to enlarge the record again to support storing 64-bit mtime
values (which I think is worth doing), then that will necessarily break
backwards compatibility.
Given that, this provides an opportunity to store 64-bit mtime and filesize
values conventionally as 64-bit big-endian integers without the need for bit-
manipulation gymnastics.
--
David McBride <dwm37@cam.ac.uk>
Unix Specialist, University Information ServicesAttachment:
signature.asc
Description: This is a digitally signed message part