A file can be set to be exclusive open by applying the exclusive open
) file type modifier. When set, only one user at a time will be able to open a file for editing.
Setting the Exclusive Open file type modifier
Regular users can set the +l file type modifier when adding new files:
$ p4 add -t binary+l clientMod.jar
or when editing existing files:
$ p4 edit -t binary+l serverMod.jar
The same can be done from the Perforce Visual Client (P4V) by right-clicking a file marked for add or edit and choosing 'Change Filetype' to add the +l
file type modifier.
Regular users should be aware the main use case for the +l
file type modifier is for cases when merging changes from multiple authors is not possible, and that when setting the +l
file type modifier the default action when integrating changes made to such files is to propagate the file type as part of the integration. Consider these carefully before making use of the +l
file type modifier.
Helix Server Administrators can use the server typemap
to automatically set the +l
file type modifier when files are submitted to the server based on file extension and/or depot path. Administrators can supplement the typemap with the use of command or change triggers
to implement site wide locking policies and to prevent end users from overriding typemap generated file type settings.
For existing files, a server administrator can use the p4 retype
command to add the +l
file type modifier. For example, adding the +l
file type modifier to existing files stored as binary
$ p4 retype -t binary+l clientMod.jar
//depot/main/clientMod.jar#2 - binary now binary+l
//depot/main/clientMod.jar#1 - binary now binary+l
Note, if the files retyped are already checked out by users, those users will need to revert and edit the file to get the file type update. For example, a user has the file opened before the retype above was executed and doesn't have the +l modifier set:
$ p4 opened
//depot/main/clientMod.jar#2 - edit default change (binary)
The user can use p4 revert -k followed by p4 edit -t to reopen the file with the +l modifier:
$ p4 revert -k clientMod.jar
//depot/main/clientMod.jar#2 - was edit, cleared
$ p4 edit -t binary+l clientMod.jar
//depot/main/clientMod.jar#2 - opened for edit
$ p4 opened
//depot/main/clientMod.jar#2 - edit default change (binary+l) *exclusive*
Note, the -k
option to p4 revert
leaves the content of the client workspace file intact as part of the revert process which preserves any changes the user has made.
Removing Orphaned Locks
Exclusive locks are removed only when the file is submitted or reverted. If a user that has a file exclusively checked out is not available, an administrator can forcefully revert the checkout which will remove the exclusive lock.
In commit/edge environments, when +l file types are opened, the exclusive locks are recorded globally across the commit/edge environment to enable enforcement of the exclusive checkout. The p4 opened -x command is used in commit/edge environments to report on files that are exclusively opened. In some cases, it's possible for global lock records to become orphaned.
To find orphaned locks, run
$ p4 opened -x //<depot>/<dir>/<file>
//<depot>/<dir>/<file> - bruno@gabriel *orphaned*
To remove an orphaned lock, use p4 unlock -x file against the server the orphaned record is reported against. With 2015.2 and later servers, on the commit server, an administrator may specify p4 -c client unlock -f -x file to unlock the global exclusive locks of files which aren't marked orphaned.
p4 -c <client> unlock -f -x //<depot>/<dir>/<file>
where the files is of type +l (exclusive lock) and -c is listed. Files from a stream client in particular must specify the -c <streamclient> argument or else the "no such file(s)" error will appear.
If the file was previously an exclusive lock, you may see "unknown"
$ p4 opened -x //mydepot/mystream/myfile
//mydepot/mystream/myfile - bruno@gabriel <unknown>
If so, change the file back to an exclusive lock file, then rerun "p4 unlock -x