CVS lock issue

[Glasgow, Steven R CIV USARMY TRAC (US)]

Hello CVS community,

I was wondering if anyone would be able to shed a little light on what may have caused a problem I encountered.

We are using RHEL Workstation 7.3 and CVS version 1.11.23.

One of our developers was tagging a module when the error occurred. Here is the output....

.
.
.
T <path>/<filen>.cc
T <path>/<filen>.h
T <path>/<filen+1>.cc
T <path>/<filen+1>.h
cvs [tag aborted]: could not open lock file `<path>/,<filen+2>.cc,`: File exists

How is it possible that the ,<filen+2>.cc, lock already existed?

Thank you,
Steve Glasgow

[Spiro Trikaliotis]

Hello,

* On Thu, Feb 15, 2018 at 07:42:30PM +0000 Glasgow, Steven R CIV USARMY TRAC (US) wrote:

> cvs [tag aborted]: could not open lock file `<path>/,<filen+2>.cc,`: File exists
>
> How is it possible that the ,<filen+2>.cc, lock already existed?

Have a look into the file, especially the date and time. Is it (very)
old?

There might have been an older operation that did not correctly finish,
and the lock file has been left over. In this case, the lock file would
be rather old. I would consider removing it by hand, then.

If it is not old, then something else is going on, and I would refrain
from removing it.

HTH,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

[Glasgow, Steven R CIV USARMY TRAC (US)]

The file is no longer there. This error occurred on Feb 01 according to a log file we maintain. We just noticed that the entire module did not get tagged. Could it be that a subsequent process to that area of the module already removed the lock sometime between then and now?

I wish the file was still there, but it's not.

Why would a lock file not get deleted?

Thanks,
Steve


-----Original Message-----
From: info-cvs [mailto:info-cvs-bounces+steven.r.glasgow.civ=mail...@nongnu.org] On Behalf Of Spiro Trikaliotis
Sent: Thursday, February 15, 2018 2:00 PM
To: info...@nongnu.org
Subject: [Non-DoD Source] Re: CVS lock issue

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.




----

Caution-http://www.trikaliotis.net/

[Glasgow, Steven R CIV USARMY TRAC (US)]

Could it be possible that two developers tried to tag the file at the same time? I thought CVS handled that situation.

Could it be possible that one developer created the lock and a second one was not able to do that (file exists). I thought the first developer would have created the #cvs.lock directory making the second developer wait to even access the <path> directory.

[Spiro Trikaliotis]

Hello Steven,

* On Thu, Feb 15, 2018 at 08:15:06PM +0000 Glasgow, Steven R CIV USARMY TRAC (US) wrote:
> The file is no longer there. This error occurred on Feb 01 according
> to a log file we maintain. We just noticed that the entire module did
> not get tagged. Could it be that a subsequent process to that area of
> the module already removed the lock sometime between then and now?
>
> I wish the file was still there, but it's not.
>
> Why would a lock file not get deleted?

Ok, then I misunderstood you. I thought you had a permanent problem.

In this case, I assume two people tried to work on the same file at the
same time. That's how CVS handles this issue, by giving this error
message.

Best regards,

Spiro.

--
Spiro R. Trikaliotis

http://www.trikaliotis.net/

[Thorsten Glaser]

Hi Glasgow,

>The file is no longer there. This error occurred on Feb 01 according
>to a log file we maintain. We just noticed that the entire module did
>not get tagged. Could it be that a subsequent process to that area of
>the module already removed the lock sometime between then and now?

If you have a long-running operation and a short operation in between,
it’s very possible that the first one waits.

For example:

toplevel$ cvs tag foo

On another terminal:

toplevel/long/path/to/a/subdirectory$ cvs commit -m foo filename

The commit will succeed, even if it started after the tag and
will finish before it.

Normally, though, the tag operation would wait (I think; I only
experienced this yet with two commits) and then, after the short
commit has finished and removed its lock files, continue.

But, as I said, lockfile names are not like the ones you indicated.

Good luck,
//mirabilos
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr

[Thorsten Glaser]

Glasgow, Steven R CIV USARMY TRAC (US) dixit:

>How is it possible that the ,<filen+2>.cc, lock already existed?

These are not lock file names. Lock files are named like #cvs.*,
and there are several types of locks. Furthermore, a promotable
lock is obtained beforehand, and only converted into a write lock
when actually writing to the target file.

Please see section 2.2.6 “CVS locks in the repository” in the
Cederqvist (“info cvs” on the command line).

Obscuring filenames like that will not get you useful debugging.

bye,
//mirabilos
--
13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs
13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you
13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺
16:06⎜<Draget:#cvs> Thank god I found you =) 20:03│«bioe007:#cvs» mira2k: ty
17:14⎜<ldiain:#cvs> Thanks big help you are :-) <bioe007> mira|nwt: ty again
18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o
18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 23:03⎜«mithraic:#cvs» aaah. thanks
18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-)
18:10⎜«sumit:#cvs» mirabilos: oh ok.. thanks for that
21:57⎜<bhuey:#cvs> yeah, I really appreciate help
18:50⎜«grndlvl:#cvs» thankyou 18:50⎜«grndlvl:#cvs» worked perfectly
20:50⎜<paolo:#cvs> i see. mirabilos, thnks for your support
00:36⎜«halirutan:#cvs» ok, the obvious way:-) thx
18:44⎜«arcfide:#cvs» mirabilos, I am running OpenBSD. 18:59⎜«arcfide:#cvs»
Hrm, yes, I see what you mean. 19:01⎜«arcfide:#cvs» Yeah, thanks for the help.
21:33⎜«CardinalFang:#cvs» Ugh. Okay. Sorry for the dumb question. Thank you
21:34⎜<centosian:#cvs> mirabilos: whoa that's sweet
21:52⎜«garrett__:#cvs» much appreciated «garrett__:#cvs» thanks for your time
23:39⎜<symons:#cvs> this worked, thank you very much 16:26⎜<schweizer:#cvs> ok
thx, i'll try that 20:00⎜«stableable:#cvs» Thank you. 20:50⎜«s833:#cvs»
mirabilos: thanks a lot. 19:34⎜<bobbytek:#cvs> Thanks for confirming :)
20:08⎜<tsolox:#cvs> ...works like a charm.. thanks mirabilos

[Spiro Trikaliotis]

Hello Steven,

* On Thu, Feb 15, 2018 at 08:20:38PM +0000 Glasgow, Steven R CIV USARMY TRAC (US) wrote:
> Could it be possible that two developers tried to tag the file at the
> same time? I thought CVS handled that situation.

It is enough that two developers try to do anything on the same file,
and you will get that message.

As CVS cannot guarantee "atomic" operations, that's the way it handles
such problems: It gives you an error, and you have to look what it did,
and what it did not, and how you can resolve this.

This is one of the reasons CVS is essentially abandoned nowadays, and
replaced by SVN (which can handle atomic operations), or even other
tools like git, mercurial, and so on.

> Could it be possible that one developer created the lock and a second
> one was not able to do that (file exists). I thought the first
> developer would have created the #cvs.lock directory making the
> second developer wait to even access the <path> directory.

No, unfortunately, that's not how CVS works. There is no wait for the
lock.

[Thorsten Glaser]

Spiro Trikaliotis dixit:

>No, unfortunately, that's not how CVS works. There is no wait for the
>lock.

This is wrong, I’ve seen waits for locks, at least between two
concurrent commit operations.

Also, please do not give advice towards ugly things like SVN
on this mailing list. Thank you.

bye,
//mirabilos
--
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs

[Spiro Trikaliotis]

Hello Thorsten,

* On Thu, Feb 15, 2018 at 08:40:03PM +0000 Thorsten Glaser wrote:
> Spiro Trikaliotis dixit:
>
> >No, unfortunately, that's not how CVS works. There is no wait for the
> >lock.
>
> This is wrong, I’ve seen waits for locks, at least between two
> concurrent commit operations.

You're right, I was wrong. CVS waits for locks, but it this is not
always successfull, so it fails in some cases. Because it fails
sometimes, I said that it fails always, which is clearly wrong.

[Glasgow, Steven R CIV USARMY TRAC (US)]

Hello Spiro,

Thank you; you have been most helpful, but here is what I think is going on. I have a hunch the source of the problem is ... tagging doesn't follow the same locking guidelines as committing or checking out. We see "waiting for xxxx's lock in yyyy" all the time. CVS does control locking on a directory by directory basis.

According to the documentation I've read before, revisited yesterday, and was pointed to by Thorston on this CVS list yesterday (after being chastised for obscuring my filenames, as if my file names add anything to the discussion):

To obtain a write lock (I assumed tagging would be doing this as it does when committing), you must first create a #cvs.lock (master lock) directory. If you can't do this for some reason (i.e., someone else already created it) wait a while and try again. This is the source of the waits we see. After you are able to create the master lock directory, check to see if there are any #cvs.rfl.<machineName> files. These would be read locks created by the user of machineName (i.e., checking out) in that directory. If there is a read lock, remove the master lock and wait a while before trying again. If there are no read locks the directory is yours and you can create a #cvs.wfl.<machineName> file. This is a write lock for the directory. Write to the file of your choice, remove the write lock, and then remove the master lock. By holding onto the master lock while writing, removing it last, you prevent anyone else from writing to that directory in the repository while you are (on a directory by directory basis).

Now in reference to our error message:

cvs [tag aborted]: could not open lock file `<path>/,<filen+2>.cc,`: File exists

Thorsten said, "These are not lock file names. Lock files are named like #cvs.*, and there are several types of locks." We already knew that, but the tagging operation clearly tried to create a file called ,<filen+2>.cc, and it called it a lock file (I didn't make that up). So, tagging seems to be doing things a little differently and not taking advantage of the master lock/write lock process.

I think this is what happened:

1) Developer #1 started tagging a module.
2) Developer #2 started tagging that same module.
3) During the course of this:
a) Developer #1 created ,<filen+2>.cc, in the <path> directory
b) Developer #2 then tried to create ,<filen+2>.cc, in that same directory but couldn't because it already existed, stopping their tagging process.
c) Developer #1 tagged the file and deleted <path>/,<filen+2>.cc, which is why it is now gone.

If the tagging process was using the locking mechanisms, developer #1 would have obtained the master lock for the <path> directory, causing developer #2's process to wait.

Could this be what is happening? Because of the speed at which tagging occurs, I see this as a VERY rare occurrence, but still a problem.

I know that CVS does not do atomic commits, but after having used CVS for over 15 years on our project, we have never had any issues. This is the first time I've ever seen this problem. CVS has supported us well. There have been many thoughts over the years about moving to Subversion, but this may have been the last straw to force us to move that direction. When the tagging of a module does not complete, it is very difficult to grab that version of the code in the future (the other option at that point would be to check out by time rather than by tag).

Thanks again,
Steve

[Mark D. Baushke]

In order to write a tag or a new revision of a file to particular
'foo.cc' in the repository, CVS must update the 'foo.cc,v' file in the
repository. After it locks the directory, it opens a new file ',foo.cc,'
which is where it starts copying the foo.cc,v along with the added line
containing the tag. When the update and copy is finished, it renames
',foo.cc,' to 'foo.c,v' and removes the write locks.

If there is a problem during the write, there are cases where the
',foo.cc,' file is left so that no information from 'foo.cc,v' is lost
(other than the update being made). This should have resulted in an
error message.

For read operations, the existence of ,foo.cc, will not be a problem.

However, for write operations, that file must not exist. A repository
maintainer must go in and see if they can salvage anything that we left
around and also possibly see if they can understand what problem arose.

In my experience, the most common case of a ',foo.cc,' file being left
around was if the repository was on an NFS filesystem and it lost some
of the file it was trying to write.

Good luck,
-- Mark