8.3 Unemulated Features

There are some features of (some implementations of) the traditional SCCS suite which it may not be desirable to copy.

1. If an SCCS file is created with the -i option, and it turns out to need encoding, then genuine SCCS seeks back to the start of the file and encodes it. However, if the input file is not seekable, for example if it is a pipe, then this doesn’t always work. The SCCS file is then sometimes created containing only the initial part of the body, before the offending segment of the file. The exit value of the admin program is nevertheless still zero. Tests for this situation are in tests/binary/seeking.sh but these tests are only carried out if the program under test seems to be CSSC rather than the genuine SCCS suite. The CSSC suite does not have this problem, and will always detect the need to encode the file, and will successfully complete the process (it does not try to seek on the input pipe).
2. The normal configuration for CSSC is that it supports binary files and has no limit on line length in file with which it deals. Both of these features may be different to the features of some version of SCCS with which you want to interoperate. See Interoperability for more information on how to achieve better interoperability with other implementations of SCCS.
3. If you have a hard link to an SCCS file, then SCCS programs would “break” the hard link because the SCCS file is rewritten. For this reason, SCCS checks the link count on the file before using it. The SCCS suite also does this. While CSSC does this consistently, SCCS does not - for example the VAL program does not do this check.

There are also a small number of respects in which various implementations differ from each other; in such cases CSSC picks a suitable alternative; SCCS Version Differences.