From: Phillip Thomas (
Date: Thu Sep 10 1992 - 20:17:55 CDT

This is a summary of my questions about SCCS and NFS. Here is my original

> I have a user who says that (once in a great while) files which are under the
> control of SCCS, are not properly locked and that other users can check out
> his files (even though they have been checked out for modification by him).
> He believes this has something to do with the fact that the files to be
> checked in and out are in an NFS mounted directory. I cannot recreate the
> problem. It always seems to work fine for me.

> Does anyone know if there are any problems using the SCCS locking mechanism
> with NFS? Is the method which SCCS uses to lock files guaranteed to *always*
> work with NFS. The Sun manuals don't mention anything.

> Also, what is the locking mechanism that the SCCS utilities use
> (sorry, we don't have source code)? Were they modified to work with NFS?

> Are there any other known problems (other than file locking) involving SCCS
> and NFS that I should be aware of?

> We are using SunOS4.1.1.


All who were using SCCS and NFS replied that they had never had a problem
such as this.

Many replied that I should check and make sure that all users have distinct
userid's. I will certainly do this.

Many replied that this could be a problem with lockd/statd and suggested using
the latest patch (100075-08) for these utilities. I believe this is not the
problem as others have replied that SCCS uses the method of creating a lockfile
in the SCCS directory as it's locking mechanism and does not use lockd. This is
the p.<filename> file you will see in the SCCS directory after you check out a
file for editing. (I also traced rpc.lockd while using SCCS to create, checkout,
and checkin a file and rpc.lockd did not start executing)

Some people have suggested that this may be a problem with NFS attribute caching
and that the directory with the SCCS files should be mounted with the "noac"
option to mount.
option to mount.
Thanks to all those who replied and any yet to come:


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:49 CDT