Perforce Public Knowledge Base - Moving from Windows to Linux, Retaining Case-Insensitive Behavior
Downloads Blog Company Integrations Careers Contact Try Free
Menu Search
Reset Search



Moving from Windows to Linux, Retaining Case-Insensitive Behavior

« Go Back



This article describes the steps needed to move a Perforce Server from a Windows platform to a Linux platform while retaining the case-insensitivity behavior of Windows. Running the Perforce Server in non-standard case-handling mode requires using the -C1 flag. The -C1 flag was first supported in the 2010.1 version of the Perforce Server.


If you choose to use the -C1 flag, you must ALWAYS use this flag when invoking p4d operations. For example, use of this flag is necessary when starting your Perforce Server and when running checkpoint recovery operations. Prior to 2007.2, if you failed to always use the -C1 flag when invoking p4d operations, you would corrupt your Perforce database. Beginning with the 2007.2 version of p4d, inconsistent use of the (previously undocumented) -C1 flag generates a server error, rather than database corruption.

To transfer your Perforce Server installation from Windows to Linux but retain the case-handling behaviour, you need to take a checkpoint of the original database, transfer your archived files to the new platform, rebuild the database from the new checkpoint using the -C1 flag, ensure the filepaths in the Perforce files repository and Map: values in the depotspec(s) are all lowercase.

  1. Stop the Perforce Server on your Windows machine
  2. Take a checkpoint
    p4d -r $P4ROOT -jc
    Checkpointing to checkpoint.17...
    MD5 (checkpoint.17) = D40173D33D630180BCF75DA63DEA5233
    Rotating journal to journal.16...
  3. Copy the checkpoint to the Linux machine's P4ROOT directory
  4. Rebuild your database from the checkpoint, being sure to include the -C1 flag:
    p4d -r $P4ROOT -C1 -jr checkpoint.17
    Perforce db files in '$P4ROOT' will be created if missing...
    Recovering from checkpoint.17...
  5. Copy the archive files to the appropriate locations on your Linux machine, converting line-endings where appropriate.  Important: all target filepaths must be lowercase.
  6. Start the Perforce Server, making sure you include the -C1 flag:      
                   p4d -r $P4ROOT -p 1666 -C

     7.  Run 'p4 depot depotname' to ensure its Map: is lowercase, and fix it if not.

At this point, you can run p4 verify -q //... to verify the integrity of the archive files.

As noted in the warning above, once you use the -C1 flag, you must always use it thereafter. You can maintain use of the flag by creating a wrapper for the Perforce Server, p4d. For example, creating a script similar to the one detailed below, specifying the path to your p4d executable:

exec $P4D -C1 "$@"
Name this script "p4d" and include it in the search path. Ensure that the real p4d executable is NOT included in the path. These two steps ensure that each time you run p4d, this script is launched rather than the actual executable. The -C1 flag is included automatically, and all additional parameters are passed to the p4d executable.

If you attempt invoke p4d commands against a database with different case-handling characteristics (using version 2010.1 or greater), you will receive the following error:
Perforce server error:
Database open error on db.config!
BTree Case Order Mismatch! Check p4d -Cx flag usage.


Here are some possible minor issues that could occur:
  1. Windows OS path limitations

    Windows clients have a 260 character path and filename limit. While the Linux server can accept longer paths and file names, the Windows client cannot. 

    NOTE: The path length limit is actually a 260 byte limit. If the path name is in Unicode (2 bytes for Unicode and 1 byte for ASCII), the path length limit could be much shorter than 260 characters. See the following Microsoft document:   
    See also the following KB article on submitting or syncing files with long path names:    

  2. Proxy OS vs. Server OS

          We recommend that if you have any proxies, have them on the same operating system as the server. The reasons being are:
  • Case sensitivity is handled on each operating system consistently
  • Path limits for Windows can be a  problem for a Linux Server + Windows proxy configuration. Proxy (P4PCACHE) paths already tend to be longer then server (P4ROOT) paths as proxy cache paths start with doubled depot names, for example: $P4PCACHE/depot/depot.
Related Links



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255