Re: error - "failed to create lock directory in repository"

[Brett]

Jim Hyslop wrote:
>>>We have a Mac OSX machine running cvs server.
>>>When I try to commit a new file under test/testdir, I get the following
>>>message:
>>>
>>># Command Aborted.
>>># commit -m "test" test.rtf
>>># cvs server: failed to create lock directory in repository
>>># `/usr/local/cvsrepository/test/testdir': No such file or directory
>>># cvs server: lock failed - giving up
>>># cvs [server aborted]: lock failed - giving up
>>>
>>>there is no file "testdir" in that directory, but there is one in the
>>>main cvs repository directory.
>
> There better not be a *file* named 'testdir' in those directories,
> because CVS is treating it as a directory.

There isn't.

> CVS is trying to create a directory named
> /usr/local/cvsrepository/test/testdir/#cvs.lock
>
> Obviously, in order to create that directory, the user must have write
> access to /urs/local/cvsrepository/test/testdir
>
> Your statements above seem to imply that
> /urs/local/cvsrepository/test/testdir is not part of your repository. If
> that's the case, then check the LockDir setting in the CVSROOT/config
file.

The config file hasn't been modified from the original. There is no
specific lockdir.

>>>Doing this test works fine from a PC works, but not from another mac
>>>running as this user.
>>>
>>>This user seems to have write access to the cvs repository and the
>>>CVSROOT directory.
>
>
> "Seems to have write access"? Please be specific - does the user have
> write access or not? That's critical to this problem.

The user HAS write permissions in that folder. Doing the same thing
from WinCVS on a PC is not a problem.

Even though the command fails, I notice it is leaving the directory it
was trying to create in /usr/local/cvsrepository/ rather than
/usr/local/cvsrepository/test. This seems different to how you explain
how it works above, and presumably why I get the error message in the
first place.

I HAD thought this was a cvs server problem, but when I changed
clients from "SmartCVS" (v4.0.8) to the MacCVSClientX the problem went
away. Is it the client after all?

Thanks for your help,
Brett.