>Submitter-Id: net
>Originator: [EMAIL PROTECTED]
>Organization: MasterLink INC.
>Confidential: no
>Synopsis: Lock file leak
>Severity: non-critical
>Priority: medium
>Category: cvs
>Class: sw-bug
>Release: cvs-1.10
>Environment:
System: Linux monster 2.2.13 #19 SMP Thu May 18 21:00:09 EDT 2000 i686 unknown
Architecture: i686
>Description:
Stale lockfile is left when attempt to check in file fails (in possibly
unexpected way)
>How-To-Repeat:
OK, first off, the reason ... I copy my CVS repository between major
versions, removing Attic files and such. I prefer this to using
branching.
The thing is, I wanted to set it up so that only I could write to
the closed branches, without denying others write access to the
active part of the project. This was to prevent people accidentally
checking in production code in stable releases.
SO, what I did was to chown all the files and directories in the tree
to my user, and then set the sticky bit on all the directories, so that
people would be able to create and delete lockfiles to access the
directory, but would not be able to update the project ... except me.
Thinking this was rather cleaver, especially since it would even work
for local users, I tested my attempt, with good results. However, there
was one problem: When an attempted checkin failed, the ',filename,'
lock file was not removed. I'm suspecting that the author did not
expect a permission denied in a directory where he had already created
a lock file, or thought that if he got on he would fail to remove his
lock file anyway, so he didn't try.
So the request is for a more graceful cleanup when a checkin fails.
>Fix:
The only fix I can think of is to run a little script that does the
following:
1) wait until there are no CVS processes running .... I suspect that
this would imply there should be no lockfiles.
2) somehow prevent cvs from running ... perhaps chmod the executable?
3) remove stale lock files.
Probably a graceful exit would be a better fix. <G>
