p4 unlock

Release the lock on one or more files.

Syntax

p4 [g-opts] unlock [-c change | -s shelvedchange | -x] [-f] [file ...]
p4 [g-opts] -c client unlock [-f ] -r

Syntax conventions

Description

Files might be locked on a server from a failed submit from a client workspace. To unlock those files:

p4 [g-opts] unlock [-c change | -s shelvedchange | -x] [-f] [file ...]

This releases locks that were created explicitly using the p4 lock command, or implicitly during the course of a submit operation.

If the file is open in a pending changelist other than default, use this command's -c option to specify the pending changelist.

If no changelist is specified, p4 unlock unlocks files in the default changelist.

If no file name is given, all files in the designated changelist are unlocked.

By default, files can be unlocked only by the changelist owner, who must also be the user who has the files locked. However, administrators on the commit server can use the -fx option. For example:

p4 unlock -fx readme.html

Note

Consider that when the administrator uses the -fx option, the administrator undoes a feature of the +1file type described at File type modifiers. The exclusive lock for editing of the +1file type is meant to prevent other users from being able to affect the file.

For an alternative approach to managing the files of an absent user, see the Perforce Knowledge Base article, Reverting Another User's Files.

Commit-edge architecture: Files might be locked on a commit server from a failed p4 submit or a failed p4 unlock from an edge server.

To unlock those files on the commit server, either the user who issued the failing command unlocks them:

p4 -c workspace-name unlock -r

or an administrator forces unlocking with the -f option:

p4 -c workspace-name unlock -f -r

specifying the name of the workspace the files are locked in as the -c global flag to p4.

DVCS: Files might be locked on a remote sever from a failed p4 push.

To unlock those files on the remote server, either the user who issued the failed push command unlocks them:

p4 -c workspace-name unlock -r

or an administrator forces unlocking with the -f option:

p4 -c workspace-name unlock -f -r

specifying the name of the workspace the files are locked in as the -c global flag to p4.
Note

If p4 unlock is called from an Edge Server, any corresponding files locked globally via p4 lock -g by that client will be unlocked on the Commit Server.

Options

-c changelist

Unlock files in pending changelist changelist. This option applies to opened files in a pending changelist that were locked by p4 lock or a failed submit operation of an unshelved changelist.

-f

The force option that allows an admin to unlock files that are locked by other users, if:

  • The files are specified in depot syntax.

  • The admin has access those files (see p4 protects). The client view is not relevant.

-r

Commit/Edge: Unlock the files associated with the specified client that were locked on the commit server due to a failed p4 submit or a failed p4 unlock command from the edge server.

DVCS: Unlock the files associated with the specified client that were locked on the remote server due to a failed p4 push command.

-s shelvedchange

If a file is locked in a pending shelved changelist, unlock it and keep it within the shelvedchange. This can typically only happen if a p4 submit -e command is aborted.

-x

In multi-server environments, unlock files that have the +l filetype (exclusive open) but have become orphaned (this is typically only necessary in the event of an extended network outage between an edge server and the commit server).

g-opts

See Global options, and in particular the -p and -c options.

Usage Notes

Can File Arguments Use Revision Specifier? Can File Arguments Use Revision Range? Minimal Access Level Required

No

No

write

admin for -f

Related commands

To lock files so other users can’t submit them

p4 lock

To display all your open, locked files (UNIX)

p4 opened | grep "*locked*"