Structural Informatics Group (SIG) logo
Home | Projects | Demos | Downloads | Publications | Local Info | About Us | New site
Go to the first, previous, next, last section, table of contents.

Special Files

In normal circumstances, CVS works only with regular files. Every file in a project is assumed to be persistent; it must be possible to open, read and close them; and so on. CVS also ignores file permissions and ownerships, leaving such issues to be resolved by the developer at installation time. In other words, it is not possible to "check in" a device into a repository; if the device file cannot be opened, CVS will refuse to handle it. Files also lose their ownerships and permissions during repository transactions.

If the configuration variable PreservePermissions (see section The CVSROOT/config configuration file) is set in the repository, CVS will save the following file characteristics in the repository:

Using the PreservePermissions option affects the behavior of CVS in several ways. First, some of the new operations supported by CVS are not accessible to all users. In particular, file ownership and special file characteristics may only be changed by the superuser. When the PreservePermissions configuration variable is set, therefore, users will have to be `root' in order to perform CVS operations.

When PreservePermissions is in use, some CVS operations (such as `cvs status') will not recognize a file's hard link structure, and so will emit spurious warnings about mismatching hard links. The reason is that CVS's internal structure does not make it easy for these operations to collect all the necessary data about hard links, so they check for file conflicts with inaccurate data.

A more subtle difference is that CVS considers a file to have changed only if its contents have changed (specifically, if the modification time of the working file does not match that of the repository's file). Therefore, if only the permissions, ownership or hard linkage have changed, or if a device's major or minor numbers have changed, CVS will not notice. In order to commit such a change to the repository, you must force the commit with `cvs commit -f'. This also means that if a file's permissions have changed and the repository file is newer than the working copy, performing `cvs update' will silently change the permissions on the working copy.

Changing hard links in a CVS repository is particularly delicate. Suppose that file `foo' is linked to file `old', but is later relinked to file `new'. You can wind up in the unusual situation where, although `foo', `old' and `new' have all had their underlying link patterns changed, only `foo' and `new' have been modified, so `old' is not considered a candidate for checking in. It can be very easy to produce inconsistent results this way. Therefore, we recommend that when it is important to save hard links in a repository, the prudent course of action is to touch any file whose linkage or status has changed since the last checkin. Indeed, it may be wise to touch * before each commit in a directory with complex hard link structures.

It is worth noting that only regular files may be merged, for reasons that hopefully are obvious. If `cvs update' or `cvs checkout -j' attempts to merge a symbolic link with a regular file, or two device files for different kinds of devices, CVS will report a conflict and refuse to perform the merge. At the same time, `cvs diff' will not report any differences between these files, since no meaningful textual comparisons can be made on files which contain no text.

The PreservePermissions features do not work with client/server CVS. Another limitation is that hard links must be to other files within the same directory; hard links across directories are not supported.

Go to the first, previous, next, last section, table of contents.