Comment 4 for bug 1710911

juliank: From what I can see, cache files generated by apt-ftparchive do not contain versioned entries. They can also be located anywhere on a machine's filesystem, depending on how the sysadmin chose to apply the utility; there isn't one canonical file that can be automatically refreshed on package upgrade.

At present, the ':st' part of a cache entry has the following structure:

   enum FlagList {FlControl = (1<<0),FlMD5=(1<<1),FlContents=(1<<2),
                  FlSize=(1<<3), FlSHA1=(1<<4), FlSHA256=(1<<5),
                  FlSHA512=(1<<6), FlSource=(1<<7)

[...]

   // WARNING: this struct is read/written to the DB so do not change the
   // layout of the fields (see lp #1274466), only append to it
   struct StatStore
   {
      uint32_t Flags;
      uint32_t mtime;
      uint64_t FileSize;
      uint8_t MD5[16];
      uint8_t SHA1[20];
      uint8_t SHA256[32];
      uint8_t SHA512[64];
   }

(From ftparchive/cachedb.h)

One of my colleagues has pointed out that my original suggestion of checking the lower four bytes for null values will misbehave if the corrected code is asked to record information for a file that is an exact integer multiple of 4GB. You could stat the file on the filesystem in this case to resolve the ambiguity.

Alternatively, you could modify the data-structure above to make it unambiguous what kind of record is being read:

* A flag bit could be used in Flags;
* An explicit version field could be added to the end of this struct.
* The use of the cache to store package file sizes could be discontinued in favour of always statting the file-size directly;
* The packed data-structure could be discarded completely, in favour of storing different pieces of metadata in independent DB keys.