Re: [Gnu-arch-users] inode signatures for .id files, and detecting file renames in pristines.

[Tom Lord]

    > From: Robert Collins <address@hidden>

    > I've added a test case to=20
    > address@hidden/tla--inode-sigs--1.2
    > that detects file renames within a pristine or rev library.

    > To fix this, I've added a :path=3D<thepath> to the inode signatures
    > generated. This has a sideffect of (once again) breaking inode signature
    > compatibility.

    > Now, with the ctime removal, Tom solved that by removing the cruft on
    > reading of the signature. However, for the path it's harder: we need to
    > add that information, and it's not present. We could snap a new
    > signature (and trust that the pristine/library hasn't been corrupted to
    > date)... I'm not keen on that because it may hide problems. Or we could
    > simply say 'time to rebuild, suckers!'. I'm soliciting opinions.

I don't understand the approach you've taken.

Both revlibs and pristine trees have a cached inventory which is
separate from the inode signature data.    Why can't you use that
cached inventory to achieve your goals?



    > Now, to optimise signatures for .id based tags, we need to check the
    > inode stat signature for both the file FOO, and .arch-ids/FOO, and not
    > read the file if both exist and are consistent. I'm still stepping
    > through the logic, but AFAICT we need the path available in the inode
    > sig code, to check that the id and actual file haven't been separated -
    > without reading either file's contents.

You may need to toss in some extra parameters for the path mapping but
I don't think that there's a need for a :path field in the inode
signature files.

-t