Run as administrator
Perforce programs like the Perforce server and P4V need to be installed from an administrator command prompt. Logging in as a Windows user with adminstrator privileges is not sufficient. You must also right-click a command prompt to select "Run as administrator". On Windows 2012, place a command prompt on the taskbar (not the desktop) and right-click "Run as administrator". Then change to the proper directory to install programs and run scripts that require elevated permissions.
Note that network drives are not available when running as administrator. If you receive a "System error 5 has occurred.", use the "net use" command to
reconnect any network drives.
Windows system limitations
The following Windows limitations affect all Windows programs, including Perforce.
- Unlike UNIX, there is no atomic renaming of files on Windows. Renaming is a two-step process, wherein a file is deleted and then a new file is put in its place. As a result, a file might not exist when being replaced in the archive or synced to a client.
- Windows does not allow deletion of a file that is locked for read. This limitation can cause problems when syncing or submitting files. This problem is indicated by messages like "Cannot unlink file" or "File in use by another process."
In all cases, however, Perforce returns appropriate error messages, and problems can be corrected by re-trying the operation. The errors are not fatal and do not corrupt the Perforce metadata.
Long File Name Support
As of Perforce release 2015.2 and later, Windows long file name support now defaults to enabled. This is equivalent to this tunable setting, "filesys.windows.lfn=1".
The following setting no longer needs to be configured on clients, "-vfilesys.window.lfn=1".As of Perforce release 2015.1, the Windows platform can now support filenames longer than 260 characters.
You can enable long filename (LFN) support on the server and client with the "filesys.windows.lfn" configurable. This tunable must be set where ever this functionality is required, Client and Server.
Turning on LFN support on a Perforce server:
p4 configure set filesys.windows.lfn=1
Turning on LFN support for a Perforce proxy:
p4 set -S "Perforce Proxy" P4POPTIONS="-v filesys.windows.lfn=1"
Turning on LFN support for clients requires adding the global option "filesys.windows.lfn=1" to your commands. There are two ways to do it - via the command line option or via using a P4CONFIG file. If you are using a P4CONFIG file, simply add the following into your configuration file:
Alternatively, you can create a wrapper for the p4.exe command and add the "-vfilesys.windows.lfn=1" option to all Perforce commands. For example:
"C:\Program Files\Perforce\p4.exe" -vfilesys.windows.lfn=1 %*
If you are running older server and/or client releases, there are ways to avoid this issue by making file paths shorter, some of which are:
- Locate your root directory, such as P4ROOT or P4PCACHE, towards the top of your Windows directory hierarchy, or in a folder at the drive root.
- Reduce folder and filename lengths
- Reduce the number of levels of folders within your file tree.
- Create a virtual drive for part of a path by using the "subst" command. Use the shorter virtual drive path with Perforce. For example, to substitute "U:" for a long directory name such as:
within a client specification, use the following command from an MS-DOS prompt:
subst U: F:\p4user\ClientName\LongDirectory\Name
Subsequent references to "U:\" still operates on the longer path.
If you expect to have extremely long paths you may wish to consider using an alternate operating system to host your Perforce installation.
For more information on long path names see Submitting Files With Long Path Names.
Windows Filesystem Limitations and Long File Name (extended path) support
Under Windows, Perforce clients and servers are subject to the maximum path length limitations inherent in the underlying version of Windows being used. Maximum path lengths range between 254 and 260 characters. Attempts to use paths longer than the limit result in errors. Any requested operation using paths >260 does not complete successfully and often generates a warning of:
The system can not find the path specified.
This path length limitation is based on the MAX_PATH parameter in the Win32API which is defined as 260 characters. This limitation is documented by Microsoft here:
Some examples of errors you might encounter include:
- Using the Perforce Proxy server on Windows
WARNING: Proxy could not update its cache.
File is \LongFileName.c
The system cannot find the path specified
Open for write: \.tmp
The system cannot find the path specified
Upgrading from Windows XP to Windows 7: P4V "Access Denied" errors on sync
After upgrading from Windows XP to Windows 7, you may encounter "Access Denied" errors when syncing files to a workspace. The likely cause is the "Root" for the workspace uses a junction point under Windows 7. This is not a "permissions" issue.
For example: If the Windows XP workspace root was "C:\Documents and Settings\<username\Workspace", you will get "Access Denied" errors if you try to sync to this location on Windows 7. That location is a junction point in Windows 7, and P4V does not support junction points.
One can work around this problem by creating a new workspace, or changing the root of their workspace to map to a non-junction point directory. In the previous example changing the workspace root to "C:\Workspace" will likely solve the issue.
For more information about junction points, see these Microsoft articles:
Contact Perforce Support if assistance is needed moving local edits between workspaces.
Access is denied
Many times, "Access is denied" issues are caused by a directory permissions problem. To check this, as a Windows user that encounters this problem, write a file into the problem directory and erase it as the same Windows user. If you cannot perform these steps, you will need to fix directory permissions.
If you can write and erase files in the problem directory and still receive "Access is denied", check whether a file by the same name is already in the directory. You may have to use the Windows attrib command to remove read-only permissions before renaming or erasing the existing file.
attrib -R filename
If P4V is behaving differently on Windows 7 than Windows XP (for example, drag-and-drop from Windows Explorer not working properly), quit P4V and follow these steps:
- Right-click the program icon and select the "Properties" menu item.
- Click the Compatibility tab to select it.
- Select (check) "Run this program in compatibility mode for:"
- Select "Windows XP (Service Pack 3)" from the drop-down menu.
- Close the properties window.
When P4V is next launched the issues with drag and drop will be resolved.
Disable User Account Control
Windows 7, Windows Server 2008, and Windows Vista have a security component called User Account Control (UAC). If you have problems installing or upgrading Perforce, disable this feature.
To install Perforce on Windows computers, use the Perforce Windows Installer (available to download from the Perforce Software website), which correctly manages changes in the environment and can install the server as a Windows service.
Windows 32-bit limitations
The Windows 32-bit platform (including Windows 2000 and 32 bit versions of Windows 2003, XP, and Vista) has a 2GB per-process memory utilization limit. On Windows, the Perforce Server runs as a single process, servicing each client request as a thread within that process. For sites with a very large transaction volume, this 2GB limitation can inhibit performance and large operations. The Windows 64-bit platform does not have this memory limitation.
Windows version limitations
The Perforce Server is not supported on Windows 95 or Windows 98, because these operating systems do not support sufficient file locking.
Windows Vista, by default, does not allow a user to write directly to "Program Files". This write protection can cause problems when a user is restoring a Perforce Server from checkpoint and their P4ROOT is under "Program Files". The restoration does not fail, instead the write is silently redirected to the user's virtual store. The problem can be resolved by moving the P4ROOT directory out of "Program Files", or having an administrator change the permissions on the "Program Files\Perforce\" directory to allow other users "write" and "modify" access.
Windows wildcards on the command line
If the command line client is used with wildcards like asterisks, surround the command with quotes as seen in "Windows wildcards".
p4 dirs "//depot/*"
Do not run the Perforce Windows server on a Novell filesystem, or any filesystem that only supports the 8.3 naming scheme. Perforce database files have long suffixes and under the 8.3 naming these file names are folded. Both NTFS and the NT implementation of the FAT16 DOS filesystem support long file names. The FAT32 filesystem under Windows 2000 is also supported. It is recommended that a network mounted filesystem not be used for the Perforce server root. While this configuration does work, severe performance degradation can be expected. This performance degradation is due to network latency, disk access, and filesystem locking considerations.
Service Pack requirements
Perforce requires Service Pack 6a when using Windows NT, and Service Pack 3 when using Windows 2000. There are no special requirements for other Windows operating systems.
Configuring the editor
By default, the Windows client uses notepad as an editor and an internal diff routine. If $SHELL is set, Perforce assumes that you have installed the MKS toolkit, and uses vi as its default editor. To override this default, set the environment variables P4EDITOR and P4DIFF.
Using multiple drives for the client workspace
On Windows, a client workspace can span multiple drives. To enable this feature, specify a client root using the keyword null. Specify the drive letter in each line of the client view. The following is a sample client specification for the client named foocli.
Created by joe.
Options: noallwrite noclobber nocompress crlf unlocked nomodtime normdir
Syncing files into the root of a Windows network share
Attempts to sync depot files to the root of a Windows network share fail. For example, in the case of this client specification fragment:
Attempts to sync //depot/file.c result in an error. The client tries to make the directory "\\". This happens to any file that maps into the root of a share via its UNC path.
There are two workarounds for this:
- Map a network drive and use the drive letter instead of the UNC path
- Create a directory under the share root which is used as the client root and which is guaranteed to exist.
On Windows the Perforce client executable performs wildcard expansion directly (via setargv.obj) rather than relying on the shell. While this works well with both the DOS box (which does not do wildcard expansion) and the MKS Korn Shell (which does), it means that to get a * past the Perforce client under the Korn Shell, you must quote it twice ( '"*"' ): once to get past the Korn Shell, and once to get past the wildcard expansion in the Perforce client.
Filenames containing tilde (~)
To avoid inadvertently overwriting files when syncing to a Windows computer, do not use the tilde character in filenames. The Windows operating system uses the tilde to represent long filenames, and attempts to expand such filenames when you sync.
Filenames containing double quotes (")
You can not use quotes in filenames on NTFS filesystems. For domains with quotes in the name such as labels, you will be able to create the domain, however the spec archive will not be created.
p4 label label"with_quotes"_1
p4 verify //spec/label/label"with_quotes"_1
//spec/label/label"with_quotes"_1.p4s#1 - add default change (ctext)
To resolve the MISSING errors, you will need to obliterate the spec with p4 obliterate and by escaping the quotes:
p4 obliterate //spec/label/label\"with_quotes\"_1.p4s#1
Filenames and reserved words
Do not use Windows reserved words as filenames. Examples:
- LPTn (where n is 1-9)
- COMn (where n is 1-9)
Starting the Perforce Server from the command line
The Perforce server executable on Microsoft Windows (p4d.exe) is a Windows console application. The application does not automatically run as a background process. Unless you are performing tests on your server, starting the Perforce Server as a Windows service is preferable to starting it as a Windows console application. The Perforce Windows installer defaults to installing the Perforce Server as a Windows Service. To start the Perforce Server as a Windows service from an MS-DOS command prompt you can use the following command: net start perforce. The server will read the environment and registry variables at startup time. These settings are discussed in the Perforce System Administrator's Guide. The order of precedence for environment variables is found in the User Guide.
Should you need to run more than one Helix Server instance on your Windows machine, please consult Installing Multiple Perforce Services for Windows.
P4V, when used in conjunction with Lotus Notes, has been known to lock up due to a bug in Lotus Notes. IBM has provided a fix, SPR# JGON5SZSK6, in Lotus Notes 6.0.4. For details on this bug, please see the fix list for Lotus Notes on IBM's website. The following workarounds are recommended:
- Upgrade Lotus Notes to 6.0.4 or higher.
- Run P4V and Lotus Notes as mutually exclusive services.
- Use P4Win instead of P4V.
If running P4V Windows installer results in a SetupDLL.cpp (524) error, this may be due to logitech video LVPrclnj.exe. To fix this issue:
- Use Window's task manager kill the task associated with LVPrcSrv.exe.
- Run the Perforce P4V installer.
- Reboot to restart LVPrcSrv.exe.
P4V loses focus, misses menu items, or cannot move to another windowThe Logitech G400 mouse needs the latest Logitech Gaming Software from their website (which installed Logitech drivers). You may have to uninstall the default Windows mouse driver from the Device Manager to fix the problem.
2007 Daylight Saving Time changes
After installation of Microsoft's patch for the 2007 Daylight Saving Time (DST) changes, all date/time queries use the 2007 method of calculating DST. Historical data from years prior to 2007 that refer to the approximately four weeks per year that are now part of DST are changed by one hour.
This causes problems for files that match the following conditions:
- Created or modified during the affected weeks in years prior to 2007
- Use the +k filetype modifier
- Use the
$DateTime$ RCS keywords
After application of the patch, p4 verify
errors, because the MD5 checksum values have changed for these file revisions. The checksums change because the dates and times returned by Windows after application of the patch differ from those returned prior to the application of the patch.
To fix this, run p4 verify -q against your depot to identify
BAD! file revisions. Then, check the contents of these revisions and run the p4 verify -v command against only the revisions affected by this problem. This tells Perforce to recalculate the MD5 checksum values for them. It is possible that some files reported as
BAD! by p4 verify -q are reported for other reasons. If you are unsure of why errors are reported for some files, contact Perforce Software's Technical Support team for assistance.
There is no DST patch for Windows Vista. It does not suffer from this problem.