3.15.4 Why val doesn't solve the whole problem
Things that paranoid people might bear in mind are
- Not all accidental changes to an sccs file will necessarily make
the file invalid.
- Since the checksum of an sccs file is of finite length, there is
a finite (though small) chance that a random change will not be
detected by the checksum
- If data is corrupted in the memory of a program, then the program will
write the incorrect data out to the history file and set the checksum
accordingly (in other words, an on-disk checksum only protects the
data while it is on the disk).
- Even if
val concludes that a history file is structurally valid,
this does not mean that the file contains what you thought it did (for
example, perhaps the file was corrupted by having another, valid,
sccs file copied over it, or perhaps it was overwritten by an old
- Consumer-grade hardware (for example commodity PCs) generally lacks
Things that an optimistic person might bear in mind are
- The chances of a random change simultaneously fooling the checksum and
the checks that
val does are very small indeed.
- Hardware failures rarely cause file corruption. The use of ECC memory
substantially reduces your changes of having undetected data
- When cssc operates on an sccs file, most of the checks that
val performs are done anyway (cssc differs slightly in this
respect from the traditional sccs toolset).
The summary is that it is theoretically possible to fool the integrity
checks performed by the sccs file checksum and by
the checksum isn't fooled often and the chances of fooling both
together are very small. The use of quality hardware reduces the
chance of data corruption yet further.