[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
val
The val
command is used to validate a (possibly suspect)
SCCS file. If an SCCS command reports that the checksum of
an SCCS file is incorrect, this may mean that the file has been
corrupted. In this case, val
may help to confirm this
(but see section Why val doesn’t solve the whole problem).
Example usages:-
val s.foo val -mfoo s.foo val -r1.2 s.foo val s.foo s.bar SCCS/s.* val /proj/python/spam/spam/eggs/spam |
3.15.1 Options for val | Full list of options | |
3.15.2 Validation Warnings | Some potential problems result in warnings | |
3.15.3 Return Value | What val’s return value means | |
3.15.4 Why val doesn’t solve the whole problem | Why your file might still be corrupt |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
val
Assert that the module name flag of the SCCS file is set to name. The return value of VAL will be zero only if all the other checks succeed and the history file has its module name flag set to this value. See section Flags, for a description of the SCCS file flags.
Silent operation; suppress any error or warning messages that would otherwise be emitted; the return value of the program will still indicate the existence and general nature of any problems.
Display version information . This option does not exist in the traditional SCCS implementation.
Validation will succeed if the SID wanted is valid, unambiguous, and present in the history file.
Assert that the module type flag of the SCCS file is set to type. The return value of VAL will be zero only if all the other checks succeed and the history file has its module name flag set to this value. See section Flags, for a description of the SCCS file flags.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some possible problems with SCCS files are not definitively
errors. In these situations, val
will emit a warning message
but the validation will not fail (that is, if there are no other
problems the return value will be zero). An explanation of the
possible warnings appears below.
This message indicates that a delta exists in the history file where the “parent” delta has a delta creation time which is later than the creation time of the “child” delta. This is a warning only because the delta creation time is measured in local time, and so if two developers with different time locale settings both edit the file in a short period of time, this can happen. If all the developers who create deltas in a history file use the same timezone settings, this should not happen.
Some versions of SCCS, but not CSSC exhibit a peculiar
behaviour in these circumstances, and do not include in the gotten
file any lines apparently inserted after the date of the delta which
has been selected. This applies to get
but more importantly
also applies to the temporary file generated by DELTA which is
compared with the working copy of tyhe file. Once this has happened
there is no way to recover from this problem other than to hand-edit
the SCCS file.
This message is displayed when a “c” control line is seen in the body of the SCCS file in which the initial “c” is not followed immediately by a space. Lines of this type are used as an extension mechanism by some other SCCS implementations, notably the BitKeeper suite, and CSSC knows about this, but if it sees a construction it doesn’t recognise, this warning is issued.
This message is displayed when the ‘y’ flag of the SCCS file is set to a value which includes a keyword letter which is not known. This is harmless unless you intended to set the flag to some other value. Flags.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The value returned by the val
program depends on the outcome of
the validation as follows :-
Validation succeeded. No problems were detected. A small number of potential problems may exist without causing a non-zero return value; see Validation Warnings, for more information.
The ‘-m’ option was used but the module name did not match.
The ‘-y’ option was used but the module type did not match.
The ‘-r’ option was used but the specified SID was ambiguous, or not present in the history file.
The ‘-r’ option was used but the specified SID was invalid.
Either the named file could not be opened, or it is not an SCCS history file.
The history file is corrupt.
An invalid option letter was used on the command line.
One of the files named on the command line was not present.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Things that paranoid people might bear in mind are
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
backup version).
Things that an optimistic person might bear in mind are
val
does are very small indeed.
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 val
but
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Build Daemon on March 19, 2010 using texi2html 1.82.