When deducing the locked/unlocked state of a file, VC first looks for an RCS version header string in the file (see section Inserting Version Control Headers). If there is no header string, or if you are using SCCS, VC normally looks at the file permissions of the work file; this is fast. But there might be situations when the file permissions cannot be trusted. In this case the master file has to be consulted, which is rather expensive. Also the master file can only tell you if there's any lock on the file, but not whether your work file really contains that locked version.
You can tell VC not to use version headers to determine lock status by
nil. VC then always uses
the file permissions (if it can trust them), or else checks the master
You can specify the criterion for whether to trust the file
permissions by setting the variable
value can be
t (always mistrust the file permissions and check
the master file),
nil (always trust the file permissions), or a
function of one argument which makes the decision. The argument is the
directory name of the `RCS', `CVS' or `SCCS'
subdirectory. A non-
nil value from the function says to mistrust
the file permissions. If you find that the file permissions of work
files are changed erroneously, set
t. Then VC always checks the master file to determine the file's
Go to the first, previous, next, last section, table of contents.