[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] inode signatures for .id files, and detecting file
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] inode signatures for .id files, and detecting file renames in pristines. |
Date: |
Sun, 22 Feb 2004 14:22:32 -0800 (PST) |
> 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