Suppose I lock a file which is controlled by RCS
[root@host1:/etc/yp]# co -l group auto_home
RCS/group,v --> group
revision 1.6103 (locked)
done
RCS/auto_home,v --> auto_home
revision 1.4003 (locked)
done
[root@host1:/etc/yp]#
I see the files with ",v" generated in RCS directory
[root@host1:/etc/yp/RCS]# ls -lrth | tail -3
-r--r--r-- 1 root other 16M Feb 20 12:20 passwd,v
-r--r--r-- 1 root other 3.5M Feb 21 23:03 group,v
-r--r--r-- 1 root other 4.1M Feb 21 23:03 auto_home,v
[root@host1:/etc/yp/RCS]#
Can we determine who is holding the lock file? All of the admins use the "root" login for making the changes ( by sudo -s to become root)
If someone has already locked, I see the below message
[root@campyp:/etc/yp]# co -l group
RCS/group,v --> group
revision 1.6103 (locked)
writable group exists; remove it? [ny](n): ^C
RCS: Interrupt
RCS: Cleaning up.
[root@campyp:/etc/yp]#
Can we check who has locked the file?
In RCS, locks are stored in the header of the archive-file. Here is an example header to illustrate:
head 1.1;
access
thomas;
symbols;
locks
thomas:1.1; strict;
comment @# @;
1.1
date 2014.08.14.00.40.55; author thomas; state Exp;
branches;
next ;
desc
@@
The rlog command gives that header information:
$ rlog 2linux,v
RCS file: 2linux,v
Working file: 2linux
head: 1.1
branch:
locks: strict
thomas: 1.1
access list:
thomas
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
----------------------------
revision 1.1 locked by: thomas;
date: 2014/08/14 00:40:55; author: thomas; state: Exp;
RCS_BASE
=============================================================================
By default, the author of a lock is determined by checking environment variables LOGNAME and USER. Those are set when your users sudo, e.g., to "root". But the behavior can be overridden:
sudo, the original $USER is saved in SUDO_USER. One could reset $LOGNAME and $USER from $SUDO_USER, making locks correspond to the real users.sudo.Further reading:
No. If all your users are root, then the lock will always belong to root.
This is a dubious arrangement at best, anyway. Have users commit edits as themselves; there should be no sane reason to do these things as root in the first place.