This rename error message is usually related to Windows. Unlike Unix, on Windows when a file is "open" by a process, that file name is protected from change. The file can not be renamed until it has been closed by all processes. This error is possible for a Perforce Client or Server. The file does not need to be locked for this error to occur.
This rename error is associated with the "text" or RCS Perforce storage type. This is because a new RCS revision is added to an existing file in the Perforce repository (for example, "data,v"). The Perforce Server constructs the new RCS archive in a temporary file, "tNNNtNNN.tmp". Once the RCS archive construction is complete, the tNNNtNNN.tmp file is renamed to the original file name, such as "data,v".
If the file "data,v" is opened by the Perforce Server or another process, the rename will be blocked. The rename operation is attempted 10 times, and upon failure this error message is logged. The example error below was logged during a submit. Note the ",v" showing that the problem is on the versioned file on the Perforce server.
Operation 'rename' failed.
Librarian checkin depot/path/data failed.
RCS can't commit changes to depot/path/data,v!
File rename() failed after 10 attempts.
rename: depot/path/data,v: Cannot create a file when that file already exists.
Sometimes another variant on this error is possible:
The system cannot find the path specified.
The most common cause for this variant is the Windows filename/path length limit of 260 bytes (including slashes and drive letter).
Using the SysInternals tools, "Process Explorer" or "handle", can help determine which process has the file open. Use the binoculars in Process Explorer to find suspect processes. Run handle with a portion or all of the filename as an argument.
If a non-Perforce related process has the file open, assist the user with preventing this in the future. This might involve tuning a Virus scanner to avoid the Perforce Server root directory.
A slow "p4 sync" operation can block a "p4 submit" operation. The sync may involve a very large RCS archive or a slow network connection. If a submit occurs concurrently, the sync may have an archive file open and block the submit.
In this case, perform an assessment on the size of the RCS archive file. If the size of the versioned file is over 1 MB, change the file to +C compressed text rather than text. The compressed text, or ctext filetype will be store files as compressed text and perhaps run faster. More importantly, each revision will be stored separately, so one process can be accessing one revision (sync) while another process will be writing a new revision (submit) which avoids conflicts.
To change the filetype of a file to compressed text, use the -t +C flag:
p4 edit -t +C file.txt
p4 submit -d "changing filetype to text+C"