Fri 06 Feb 2004 11:50:44 PM UTC, comment #1:
I would agree that using MD5 for the sigs would make more sense than raw inode information.
Using MD5 would also give a good opportunity to further optimize the library by linking duplicates.
I would propose the sigs store the following information:
File ID, size, mtime, MD5 hash, then use the follwing criterias when verifying library integrity
1. If size differs then library corrupt.
2. If mtime is correct then let normal operations assume the file is correct.
3. If mtime differs then calculate the MD5. If MD5 different library corrupt. If the resulting MD5 is correct then update the ,,inode-sigs index to avoid having to recalculate the MD5 again.
A nice extension of this would be to write a "library-verify" operation which verifies the MD5 of each file in a library revision (or whole library tree) and alerts on any corruption detected.
This would also make it quite trivial to write a "library-optimize" function which reads the inode sigs of existing library revisions and links identical files to optimize disk usage beyond what the normal linking process while building the library revisions can do.
|