Re: [Gnu-arch-users] inode caching for explicit id's completed

[Tom Lord]

    > From: Robert Collins <address@hidden>

    >   I've finished inode signature cache support for explicit id's. As part
    > of the same work, I've added a path field to the inode signature, in
    > order to detect certain forms of library/pristine corruption. That work
    > is in address@hidden/tla--inode-sigs--1.2

    > I'd really appreciate a review of this code... I think I've got all the
    > cases covered.

So...er...as I mentioned: aren't the inventory caches enough?   I
don't think you really need the path field in the signature files.


    > The only thing that has me scratching my head is the addition of the
    > path field - it's not ideal for a couple of reasons:
    > * It means moved files don't match inode sigs, so moving a large file
    > will result in it being diffed, even if it hasn't changed.
    > * There is no obvious (to me anyway) to retrofit the path to existing
    > inode caches.


Well, there you go.  In pristines and revlibs, you have an inventory
and you need to actually go and stat all of those files --- so there's
enough information there already to detect
corruption-by-renaming/deletion of known-good trees.  (Stray adds
shouldn't count as corruption -- they _should_ just be ignored, I
think.)


    > I've considered an alternative approach to handling file rename
    > detection: create a new file {arch}/,,inode-sigs/revision.mapping, and
    > in there have (id path) pairs. If that file is missing, we could ignore
    > it rather than having an inode sig corruption result. And inode
    > signature matches would work correctly for renamed files.

Well, that file already exists!  (./,,index or ./,,index-by-name)

    > Thats more work than what I've done today, but I suspect it's the right
    > way.=

    > Anyway... I'm primarily interested in your opinion on the explicit id
    > support for inode signatures.

I haven't looked at the code yet.   The pseudocode in your earlier
message sounded plausible.   

How do you feel about removing the :path field before I dig into the
in-depth review?

-t