What To Do When CVS Fails to Create Lock Directory

May 4, 2005 code suggest edit

I’m posting this in the hopes that it helps someone out there with the same problem because I just KNOW how often you’re adding files using CVS. It’s the little spark that gets your juices flowing while sitting at work daydreaming about how much you can’t wait to use CVS again.

Anyways, I was creating a new CVS module and adding the contents of some source code to the repository when I heard the sound of breaking glass that TortoiseCVS uses to indicate a problem (it’s a rather lovely sound).

It seems I had some sort of network issue while adding files. No problem, I thought, I’ll just add the files that haven’t been added and then commit all the files.

Unfortunately, every time I tried commiting files I heard that dreaded breaking glass. My error message was something like:

cvs commit: failed to create lock directory for `/cvsroot/MyProject/SomeDirectory’
(/cvsroot/MyProject/SomeDirectory/#cvs.lock):
No such file or directory
cvs commit: lock failed - giving up
cvs [commit aborted]: lock failed - giving up

Well that’s strange, the error message is having trouble creating a lock for the directory “SomeDirectory” because it doesn’t exist. But when I use Tortoise CVS to add contents, it shows that everything has been added.

What I discovered is that CVS stores information about the state of the repository in local hidden folders named, you guessed it, “CVS”. If something very bad happens, it’s quite possible that the local information will get out of synch with the information on the server. That’s exactly what I ran into.

To fix it, I copied my source tree to a new directory, deleted the old source tree, and ran a Checkout command to get the latest version that actually made it into the repository. Then I copied that set aside source tree over the one I had just checked out so that all the new files made it into the tree. That then showed that I still needed to add some files and directories to the CVS repository, which I did. Finally, a commit of the source tree worked flawlessly.

By the way, I’m a relative CVS rookie, though I’ve used it quite a bit. So if there was a better way to do this, let me know.

For a great tutorial on source control, check out Eric Sink’s series Source Control HOWTO.

[Listening to: Chinese Burn (Forbidden City Remix) - Paul Van Dyk - Perspective CD2 (10:36)]

Found a typo or mistake in the post? suggest edit

Comments

26 responses

Another Perpetual CVS Rookie • May 30th, 2005
FYI: Another occasion where this happens is when you specify the wrong CVS root on a remote server and the module you are working with in your local workspace actually doesn't exist in that cvs root on the server end. In this case, just double check that you have specified the correct root.
Nathan • April 12th, 2006
I got the error because the bloke that created the directories I was trying to check out set them to read only, thus I didn't have permission to write the lock needed for checkout. So make sure the permissions on the cvs folder are set correctly.
Manish Jain • April 18th, 2006
This is realy help. I was facing this issue and tring to resolve from last 2 hour but not got the success.
These steps have worked and resolved my problem.
Thanks.
Craig Turner • June 5th, 2006
In my instance I think this was caused because I'd copied a directory including the CVS directory for it and the repository got confused because the CVS data in the subdirectory was wrong. Thanks for pointing me in the right direction.
Dan Scholten • August 31st, 2006
I'm having this problem except it is occuring when I try to check OUT the respository. Has anyone else experienced this?
PK • September 11th, 2006
Thanks so much for posting this. I'm new at setting up a CVS repository and had no idea what to do when this error came up. The other comments helped, too. :)
timmster • December 12th, 2006
Thanks for giving me a hint!
I have resolved my problem. Thank You!
Mukesh • July 23rd, 2007
The server reported an error while performing the "cvs commit" command.
: cvs server: failed to create lock directory for #cvs.lock): Permission denied
: cvs server: lock failed - giving up
: cvs [server aborted]: lock failed - giving up
Eddie • August 13th, 2007
Works like a charm thanks much!
In windows I copied the moved the problem directory to my desktop.
Did a search on this directory for the hidden CVS folders. (make sure to choose search for hidden folders and files in the windows search dialog) Then deleted all the cvs folders.
Checked out the lastest stuff and copied over it. Then cvs worked fine.
Thanks!!
Agile Being • August 21st, 2007
I Had similar problem. In my case the cvs checkout of only one of the directories did not work.
Based upon this Article & Comments i checked out the file permissions and
found out that the read-write attribs for that particular dir was 755 (which should have been 775). This caused the dir-lock failure. I changed the attribs to 775 and everything started working fine.
The problem is fixed, but i still am wondering how could the permissions get changed, since everything was working fine initially.
Leigh • March 3rd, 2008
I'm also using TortoiseCVS and this seemed to fix it. I was doing an Add Contents on a folder that did NOT exist in the repository and I THINK this was the problem.
Plus I was doing a TON of files so it would take forever and then frustration would hit. It looks like for me the problem was the directory creation in the repository failing when doing an Add Contents. If I added the directory and THEN did add contents all was well.
Thanks for the help!
Nate • March 11th, 2008
I had the identical type of error message (with the only difference being the directory name.) If you are in Linux/RedHat/Fedora/etc. you can cd into the $CVSROOT and then cd into the directory above the directory that is causing the conflict.
When you do an ls -la, check the group owner. If you see a different group owner than the one you belong to, it probably means the directory in question needs to have its group ownership corrected (or you probably need to be added to a group that you don't belong to.) You can do a 'less' on /etc/group to see if you are in the group in question.
uj • June 18th, 2008
I am new to use CVS.
I did cvs checkout , so in the existing directory list i have added new directories also. so while doing add new directories are not getting created. I am doing cvs add on command prompt / also tried with WinCVS tool.
Please guide how do i proceed?
Your help is much appreciated.
Thanks,
Uj
shipra • July 1st, 2008
siebspi_logn.exe encountered a problem and needed to close.
(in citrix).this popup window is comming whenever opening citrix server , how to solve it
Mainak • July 2nd, 2008
reasons are the directory in CVS is deleted manually or has wrong permissions.
I solved it by creating a directory in the cvs by shell and doing a chmod 777 on it.
Hope this helps
Vinay • July 8th, 2008

I am getting below error during the tagging. I tried changing the permission to 0777 for the directory in the repository. Any solution.
cvs tag: failed to create lock directory for cvs.lock_old/#cvs.lock): No such file or directory
cvs [tag aborted]: read lock failed - giving up
DanielN • August 5th, 2008
Your tip also helped me in the right direction. I backed up and removed the whole folder, used cvs up -d and everything is great!
Larry E. Ramey • November 17th, 2008
Lets get over my surprise that someone at Microsoft is allowed to use CVS and deal with the issue...
Somehow, and I'm not enough of a CVS guru to explain WHY, the server and the client got confused. Yes, this seems more likely to happen when adding a ton of files.
At some point in adding directory foo CVS creates a new directory on the client called CVS. It populates this with information about what to add to the server, then it goes to the server and creates the new directory called foo. You are getting an error after step 1 and before step 2. They way you can tell this is to go to the server and look for foo. It won't be there.
OK, to solve this, instead of using a nuclear bomb (what you suggest) we can use a scalpel. Just go to the foo directory on the client and remove the foo/CVS directory. (IF foo has subdirectories, you will have to get rid of any CVS directories in there) Now go cvs add those directories and their files again. This time it should take.

The other obvious source of this problem is a nitwit that has messed up permisions on the server... look into that before going down this road.
haacked • November 17th, 2008
@Larry this was written back in 2005 before I was at Microsoft. Besides, I use Subversion now, so you can be surprised at that. ;)
Deepak • March 19th, 2009
I checked a file as myself. But while checking out as anonymous is giving error.
cvs server: failed to create lock directory for #cvs.lock): Permission denied
: cvs server: lock failed - giving up
Michael James • February 7th, 2010
Just ran into this problem when trying to use git cvsexportcommit to commit changes from my local git repository to a central CVS repository. It turns out that there's enough of a difference between the version of CVS that TortoiseCVS uses (cvsnt, I think) and the version of CVS I installed through Cygwin, that you get this error.
Running the CVS checkout and git cvsexportcommit from Cygwin (thus using the same CVS on both commands) fixed the problem.
Taehoon kim • February 22nd, 2010
first of all....check the hard disk full...^^
AgDude • June 18th, 2010
I am running CVS on a freeNAS server, and ran into this problem when creating a module with subdirectories. For some reason the base folder for the project got the right permissions, but the subfolders did not. The tips here got me thinking in the right direction. As I have it configured I need the permission to be 775 on the server, so open an ssh shell and run: chmod 775 /path/to/subdirectory.
I repeated this for each sub folder, I didn't use the -R option, since the files have different permissions than the directories, and being new to CVS I figured this might be important to retain.
Max • July 5th, 2011
Thanks, it was helpful!
Grundstückspreise • July 6th, 2011
Great Article - Solved all a problem, that i walked around with for more then 2 months - Thanks :)
Andy B • August 4th, 2011
Not so good, guys. The reason you have a problem is because when you run cvs init to create the root, you are probably running as "root" (on *nix) or some privileged account on Windows.
Then when you add a project it is probably running as a different account.
The solution? On CVSROOT and children, make the group (which has RW privs) to be something other than (on *nix at least) "root". Same for the project. Look at how I set up on the vanilla Linux box I just created on EC2:
[root@ip-10-113-25-39 cvsroot]# ls -la
total 32
drwxrwxrwt 5 root root 4096 Aug 5 09:04 .
drwxr-xr-x 3 root root 4096 Aug 5 08:30 ..
drwxrwxr-x 3 root cvs_users 4096 Aug 5 08:32 CVSROOT
drwx------ 2 root root 16384 Aug 5 08:30 lost+found
drwxrwxr-x 17 tooyen_priv softwareab 4096 Aug 5 09:24 softwareab
I created "softwareab" group for my softwareab project (groupadd softwareab). Then I used "usermod" to ensure that both my accounts (the ec2-user SSH wheel and my local "tooyen_priv" account) have membership in bptj cvs_users and softwareab groups. Do you see the pattern? "cvs_users" group is common to all devs (hence is used for CVSROOT and children group). Individual projects (like my "softwareab") will have different group.
Individual developers will always be a member of "cvs_users" and can optionally be members of other groups to give them appropriate access to the projects. It's not perfect (for example, how to give read-only access to projects without granting that privilege to "world") but it explains the lock issues you are reporting.
Note for the unwary (excuse the shouting): DO NOT USE 777 FOR PERMISSIONS. It's really a bad idea and indicates absence of planning. It's the kind of thing that, with one little mistake like a -R (recursive) on chmod, can effectively destroy the integrity of an entire OS. Think I'm kidding? I've seen it happen up close and personal. The good news, with VMs and snapshots you can recover (unless it's a physical box in which case there went your weekend).