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

[Robert Collins]

I've added a test case to 
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=<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.

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.
Roughly, I'm planning:
  during inventory,
    when checking a file FOO:
      look for a .id file.
        if not found, follow current code path.
        if found,
          and a matching inode sig entry doesn't exist follow current
code path
          and a matching inode sig entry exists, assign the id from the
x_prefixed signature.

For makeing a changeset,
  from the x_prefixed signature, find the matching E_ prefixed inode
sig, and verify it.
            if it matches, the file hasn't been touched.
            if it doesn't match, then the file has been altered.
          
Again, any thoughts?

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part