Managing the Server and Its Resources

This chapter describes common management, maintenance, and troubleshooting tasks:

  • Managing the sharing of code
  • Managing distributed development
  • Managing users
  • Managing changelists
  • Backing up a workspace
  • Managing disk space
  • Managing processes
  • Scripted client deployment
  • Troubleshooting Windows installations

These are all tasks that go beyond the initial configuration of the server.

Forcing operations with the -f flag

Certain commands support the -f flag, which enables Perforce administrators and superusers to force certain operations unavailable to ordinary users. Perforce administrators can use this flag with p4 branch, p4 change, p4 client, p4 job, p4 label, and p4 unlock. Perforce superusers can also use it to override the p4 user command. The usages and meanings of this flag are as follows.

Command Syntax Function

p4 branch

p4 branch -f branchname

Allows the modification date to be changed while editing the branch mapping

 

p4 branch -f -d branchname

Deletes the branch, ignoring ownership

p4 change

p4 change -f [changelist#]

Allows the modification date to be changed while editing the changelist specification

 

p4 change -f changelist#

Allows the description field and username in a committed changelist to be edited

 

p4 change -f -d changelist#

Deletes empty, committed changelists

p4 client

p4 client -f clientname

Allows the modification date to be changed while editing the client specification

 

p4 client -f -d clientname

Deletes the client, ignoring ownership, even if the client has opened files

p4 job

p4 job -f [jobname]

Allows the manual update of read-only fields

p4 label

p4 label -f labelname

Allows the modification date to be changed while editing the label specification

 

p4 label -f -d labelname

Deletes the label, ignoring ownership

p4 unlock

p4 unlock -c changelist -f file

Releases a lock (set with p4 lock) on an open file in a pending numbered changelist, ignoring ownership

p4 user

p4 user -f username

Allows the update of all fields, ignoring ownership

This command requires super access.

 

p4 user -f -d username

Deletes the user, ignoring ownership

This command requires super access.

Managing the sharing of code

Users have three options in how they share code:

  • Using distributed development

    This method allows users to share code and development. Using this option, users connect to a shared server and use the p4 push and p4 fetch commands to copy files to and from the shared server. Integration with the shared server is bi-directional and both file contents and history is shared. See Distributed development using Fetch and Push for more information about this option.

  • Using the p4 zip and p4 unzip commands

    This option allows users to share code. In addition to file contents, users can see the associated changelists, fixes, file attributes and integration history. See Code drops without connectivity for additional information about this option.

  • Using remote depots

    This option enables independent organizations with separate Perforce installations to integrate changes between installations. Code integration is only one way, and metadata information cannot be accessed. This option allows code drops to expose only files and file content. This might be preferable for security reasons.

    For additional information about this option, see “Working with Depots”.

Managing distributed development

This section explains the work you need to do to support code sharing between distributed sites. This functionality is similar to using remote depots to do code drops, except that you can move file history in addition to files.

Distributed development using Fetch and Push

The following sections describe how you use the p4 fetch and p4 push commands to share code easily between distributed sites.

Consider the scenario described below.

The gaming company Ukko Productions has offices in Sweden, Argentina and the United States. Each site is responsible for a different part of the gaming code; each does development on the section of code or "component" for which it is responsible. This work happens on the office’s Perforce server, in a directory of the Perforce depot called dev. dev will contain locally submitted changes.

Let’s suppose Sweden is working on a widget which is used by the developers in Argentina and the United States. First, Sweden makes the widget code available to Argentina and the United States by dropping the code — using the p4 push into drop directories on the servers in Argentina and the United States (see "1" in the figure below). (Alternatively, the Argentina and United States developers could use the p4 fetch to copy Sweden’s code into their drop directories.) The Argentina and United States development teams can then merge the Sweden widget code into their respective dev directories using p4 merge (See "2" in the figure below). They can then customize the widget for their own purposes, without sharing these customizations with the Sweden developers.

If developers in the US and Argentina have a subset of changes they do want to share with Sweden, they use p4 push to copy this code into a special drop location on the Sweden server — one location for Argentina and one for the United States. (See "3" in the figure below). (Alternatively, Sweden could use the p4 fetch to obtain the code and drop it into the appropriate locations.) The Sweden developers can then merge the Argentina and United States code into their dev directory using p4 merge (See "4" in the figure below).

Then the cycle repeats.

This scenario is illustrated in the following drawing:

distrib devel dvcs

The next section explains how you must define remote specs to be able to implement this scenario.

Configuring the remote specifications

In order for the p4 push and p4 fetch commands to work properly, each of the three servers — Argentina’s, the United States' and Sweden’s — must have properly configured remote specifications. Remote specifications determine which remote servers a local server can fetch from or push to and which files will be fetched and pushed. (For more information about remotes and remote specifications, see the "Understanding Remotes" section of "Using Perforce for Distributed Versioning.")

Because the Argentina developers are fetching from or pushing to Sweden’s server, their server’s remote spec would look as follows: 

RemoteID: ServerSweden
Address: ServerSweden:1666
DepotMap:
  //depot/code-dropA/... //depot/Sweden-dev/...
  //depot/Argentina-dev/... //depot/code-dropS/...

Because the United States developers are fetching from or pushing to Sweden’s server, their server’s remote spec would look as follows: 

RemoteID: ServerSweden
Address: ServerSweden:1666
DepotMap:
  //depot/code-dropUSA/... //depot/Sweden-dev/...
  //depot/USA-dev/... //depot/code-dropS/...

Because the Sweden developers are fetching from or pushing to Argentina, their server’s remote spec would look as follows: 

RemoteID: ServerArgentina
Address: ServerArgentina:1666
DepotMap:
  //depot/code-dropS/... //depot/Argentina-dev/...
  //depot/Sweden-dev/... //depot/code-dropA/...

Because the Sweden developers are also fetching from or pushing to the United States, their server would have a second remote spec that would look as follows: 

RemoteID: ServerUnitedStates
Address: ServerUnitedStates:1666
DepotMap:
  //depot/code-dropS/... //depot/USA-dev/...
  //depot/Sweden-dev/... //depot/code-dropUSA/...

Code drops without connectivity

Perforce Server provides a pair of commands that enable you to move files and their associated change history between servers when there is no connectivity between the servers; they are p4 zip and its companion command p4 unzip.

The p4 zip takes the specified list of files and the changelists which submitted those files and writes them to the specified zip file. It lets you bundle up any depot path from a server — from a subset to all the files on the server — into a zip file. You can also bundle by changelist number, capturing any number of changes through history.

You can then use the p4 unzip to unzip the content of the zip file into any Perforce server or servers.

Managing users

This section describes the three types of Perforce users and explains how you can create users, add new licensed users, rename users, delete users, and manage the files of deleted users.

For information about authenticating users and granting them access, please see “Securing the Server”.

User types

There are three types of Perforce users: standard users, operator users, and service users.

  • A standard user is a traditional user of Perforce.

    Standard users are the default, and each standard user consumes one Perforce license.

  • An operator user is intended for human or automated system administrators.

    An operator user does not require a Perforce license.

  • A service user is used for server-to-server authentication, whether in the context of remote depots (see Remote depots and distributed development) or in distributed environments (see Helix Versioning Engine Administrator Guide: Multi-site Deployment.)

    Service users do not require licenses, but are restricted to automated inter-server communication processes in replicated and multi-server environments.

The following sections describe these types and how they need to be managed.

Important

Once you set the user type, you cannot change it.

Creating standard users

By default, Perforce creates a new user record in its database whenever a command is issued by a user who does not exist. Perforce superusers can also use the -f (force) flag to create a new user as follows: 

$ p4 user -f username

Fill in the form fields with the information for the user you want to create.

The p4 user command also has an option (-i) to take its input from the standard input instead of the forms editor. To quickly create a large number of users, write a script that reads user data, generates output in the format used by the p4 user form, and then pipes each generated form to p4 user -i -f.

Service users

Creating a service user for each Perforce service you install can simplify the task of interpreting your server logs, and also improve security by requiring that any remote Perforce services with which yours is configured to communicate have valid login tickets for your installation. Service users do not consume Perforce licenses.

A service user can run only the following commands:

p4 dbschema

p4 export

p4 info

p4 login

p4 logout

p4 logparse

p4 logschema

p4 logstat

p4 logtail

p4 passwd

p4 servers

p4 user

To create a service user, run the command:

$ p4 user -f service1

The standard user form is displayed. Enter a new line to set the new user’s Type: to be service; for example: 

User:      service1
Email:     [email protected]
FullName:  Service User for remote depots
Type:      service

By default, the output of p4 users omits service users. To include service users, run p4 users -a.

Tickets and timeouts for service users

A newly-created service user that is not a member of any groups is subject to the default ticket timeout of 12 hours. To avoid issues that arise when a service user’s ticket ceases to be valid, create a group for your service users that features an extremely long timeout, or set the value to unlimited. On the master server, issue the following command: 

$ p4 group service_users

Add service1 to the list of Users: in the group, and set the Timeout: and PasswordTimeout: values to a large value or to unlimited. 

Group:            service_users
Timeout:          unlimited
PasswordTimeout:  unlimited
Subgroups:
Owners:
Users:
        service1
Permissions for service users

On your server, use p4 protect to grant the service user super permission. Service users are tightly restricted in the commands they can run, so granting them super permission is safe. If you are only using the service user for remote depots and code drops, you may further reduce this user’s permissions as described in Restricting access to remote depots.

Operator users

Organizations whose system administrators do not use Perforce’s versioning capabilities might be able to economize on licensing costs by using the operator user type.

The operator user type is intended for system administrators who, even though they have super or admin privileges, are responsible for the maintenance of the Perforce Server, rather than the development of software or other assets on the server.

An operator user does not require a Perforce license, and can run only the following commands:

p4 admin stop

p4 admin restart

p4 admin checkpoint

p4 admin journal

p4 dbstat

p4 dbverify

p4 depots

p4 diskspace

p4 configure

p4 counter (including -f)

p4 counters

p4 info

p4 journaldbchecksums

p4 jobs (including -R)

p4 login

p4 logout

p4 logappend

p4 logparse

p4 logrotate

p4 logschema

p4 logstat

p4 logtail

p4 lockstat

p4 monitor

p4 passwd

p4 ping

p4 serverid

p4 verify

p4 user

  

Preventing automatic creation of users

By default, Perforce creates a new user record in its database whenever a user invokes any command that can update the depot or its metadata. You can control this behavior by setting the dm.user.noautocreate configurable with the p4 configure command:

Value Meaning

0

A user record is created whenever any new user invokes a command that updates the depot or its metadata (default).

1

New users must create their own user records by explicitly running p4 user.

2

Only the Perforce superuser can create a new user with p4 user.

For example:

$ p4 configure set dm.user.noautocreate=1

changes the server’s behavior to require that new users first create their own accounts before attempting to modify data on the server.

Adding new licensed users

Perforce licenses are controlled by a text file called license. This file resides in the server root directory.

To add or update a license file, stop the Perforce Server, copy the license file into the server root directory, and restart the Perforce Server.

You can update an existing license without shutting down the Perforce Server, use p4 license -i to read the new license file from the standard input.

Most new license files obtained from Perforce can be installed with p4 license, except for when the server IP address has changed. If the server IP address has changed, or if no license file currently exists, restart the Server with p4 admin restart.

Renaming users

You can use the p4 renameuser command to rename users. The command renames the user and modifies associated artifacts to reflect the change: the user record, groups that include the user, properties that apply to the user, and so on. For detailed information see the description of the p4 renameuser command in the P4 Command Reference. In general, the user name is not changed in descriptive text fields such as change descriptions. It is only changed where the name appears as the owner or user field of the database record.

For best results, follow these guidelines:

  • Before you use this command, check to see that the new user name does not already exist. Using an existing name might result in the merging of data for the existing and the renamed user despite the best efforts of the system to prevent such merges.
  • The user issuing this command should not be the user being renamed.
  • The user being renamed should not be using the server when this command executes. After the command completes, the user should log out and then log back in.

  • The p4 renameuser command does not process unloaded workspaces: all the user’s workspaces should be reloaded (or deleted) first.

    A distributed installation might contain local workspaces or local labels owned by the user; these workspaces and labels, which are bound to Edge Servers, should be deleted or moved to the Commit Server first.

  • Files of type +k which contain the $Author$ tag that were submitted by the user will have incorrect digests following this command. Use p4 verify -v to recompute the digest value after the rename.

Deleting obsolete users

Each standard user on the system consumes one Perforce license. A Perforce administrator can free up licenses by deleting users with the following command: 

$ p4 user -d -f username

Before you delete a user, you must first revert (or submit) any files a user has open in a changelist. If you attempt to delete a user with open files, Perforce displays an error message to that effect.

Deleting a user frees a Perforce license but does not automatically update the group and protections tables. Use p4 group and p4 protect to delete the user from these tables.

Reverting files left open by obsolete users

If files have been left open by a nonexistent or obsolete user (for instance, a departing employee), a Perforce administrator can revert the files by deleting the client workspace specification in which the files were opened.

As an example, if the output of p4 opened includes: 

//depot/main/code/file.c#8 - edit default change (txt) by jim@stlouis

you can delete the stlouis client workspace specification with: 

$ p4 client -d -f stlouis

Deleting a client workspace specification automatically reverts all files opened in that workspace, deletes pending changelists associated with the workspace, and any pending fix records associated with the workspace. Deleting a client workspace specification does not affect any files in the workspace actually used by the workspace’s owner; the files can still be accessed by other employees.

Deleting changelists and editing changelist descriptions

Perforce administrators can use the -f (force) flag with p4 change to change the description, date, or user name of a submitted changelist. The syntax is p4 change -f changenumber. This command presents the standard changelist form, but also enables superusers to edit the changelist’s time, description, date, and associated user name.

You can also use the -f flag to delete any submitted changelists that have been emptied of files with p4 obliterate. The full syntax is p4 change -d -f changenumber.

Example 10. Updating changelist 123 and deleting changelist 124

Use p4 change with the -f (force) flag: 

$ p4 change -f 123
$ p4 change -d -f 124

The User: and Description: fields for change 123 are edited, and change 124 is deleted.

Managing shelves

It’s a good idea to check periodically for stale or abandoned shelves. Based on the last time a shelf was accessed, you might decide to delete the shelf.

The command p4 -Ztag change -o displays, in addition to other information, the access time for shelved files. You can use this information to determine if a shelved file has been abandoned and needs to be removed. 

p4 -Ztag change -o 38
... Change 38
... Date 2015/10/01 16:54:47
... Client edge-one
... User markm
... Status pending
... Description shelve file

... Files0 //depot/new/code/dma/dmajob.cc
... Type public
... extraTag0 IsPromoted
... extraTagType0 int
... IsPromoted 1
... extraTag1 shelveAccess
... extraTagType1 date
... shelveAccess 2015/10/08 15:53:12

Note

When a shelf is viewed or modified, its access time is updated if its last access time was longer than the limit specified by the value of dm.shelve.accessupdate

Backing up a workspace

You can use the -o flag to the p4 unload command to unload a client, label, or task stream to a flat file on the client rather than to a file in the unload depot. This can be useful for seeding a client into another database or for creating a private backup of the client. The flat file uses standard journal format. The client, label, or task stream remains fully loaded after the command is run.

Managing disk space

You can manage disk space by minimizing the amount of space taken up by journal files and checkpoints and by relocating files. The following sections describe the strategies available for minimizing disk space use.

Diskspace Requirements

By default, the Perforce Server rejects commands when free space on the filesystems housing the P4ROOT, P4JOURNAL, P4LOG, or TEMP fall below 10 megabytes. To change this behavior, set the filesys.P4ROOT.min (and corresponding) configurables to your desired limits:

Configurable Default Value Meaning

filesys.P4ROOT.min

10M

Minimum diskspace required on server root filesystem before server rejects commands.

filesys.P4JOURNAL.min

10M

Minimum diskspace required on server journal filesystem before server rejects commands.

filesys.P4LOG.min

10M

Minimum diskspace required on server log filesystem before server rejects commands.

filesys.TEMP.min

10M

Minimum diskspace required for temporary operations before server rejects commands.

filesys.depot.min

10M

Minimum diskspace required for any depot before server rejects commands. (If there is less than filesys.depot.min diskspace available for any one depot, commands are rejected for transactions involving all depots.)

You can use the following abbreviations to specify size:

t or T for tebibytes
g or G for gibibytes
m or M for mebibytes
k or K for kibibytes

You can also use a percentage to specify the relative amount of free diskspace required. For example, setting filesys.P4JOURNAL.min to 5% means that at least 5% of total diskspace must be free for the server to continue to accept commands.

Saving disk space

All of Perforce’s versioned files reside in subdirectories beneath the server root, as do the database files, and (by default) the checkpoints and journals. If you are running low on disk space, consider the following approaches to limit disk space usage:

  • Configure Perforce to store the journal file on a separate physical disk. Use the P4JOURNAL environment variable or p4d -J to specify the location of the journal file.
  • Keep the journal file short by taking checkpoints on a daily basis.
  • Compress checkpoints, or use the -z option to tell p4d to compress checkpoints on the fly.
  • Use the -jc prefix option with the p4d command to write the checkpoint to a different disk. Alternately, use the default checkpoint files, but back up your checkpoints to a different drive and then delete the copied checkpoints from the root directory. Moving checkpoints to separate drives is good practice not only in terms of diskspace, but also because old checkpoints are needed when recovering from a hardware failure, and if your checkpoint and journal files reside on the same disk as your depot, a hardware failure could leave you without the ability to restore your database.
  • On UNIX systems, you can relocate some or all of the depot directories to other disks by using symbolic links. If you use symbolic links to shift depot files to other volumes, create the links only after you stop the Perforce service.
  • If your installation’s database files have grown to more than 10 times the size of a checkpoint, you might be able to reduce the size of the files by re-creating them from a checkpoint. See Checkpoints for database tree rebalancing.
  • Use the p4 diskspace and p4 sizes commands to monitor the amount of disk space currently consumed by your entire installation, or by selected portions of your installation. See Monitoring disk space usage.
  • If you have large binary files that are no longer accessed frequently, consider creating an archive depot and using the p4 archive command to transfer these files to bulk, near-line, or off-line storage. See Reclaiming disk space by archiving files.

Reclaiming disk space by archiving files

Over time, a Perforce server accumulates many revisions of files from old projects that are no longer in active use. Because p4 delete merely marks files as deleted in their head revisions, it cannot be used to free up disk space on the server.

Archive depots are a solution to this problem. You use archive depots to move infrequently-accessed files to bulk storage. To create one, mount a suitable filesystem, and use the p4 archive (and related p4 restore) commands to populate an archive depot located on this storage.

Note

Archive depots are not a backup mechanism.

Archive depots are merely a means by which you can free up diskspace by reallocating infrequently-accessed files to bulk storage, as opposed to p4 obliterate, which removes file data and history.

Archiving is restricted to files that meet all of the following criteria:

  • By default, files must be stored in full (+F) or compressed (+C) format. To archive text files (or other files stored as deltas), use p4 archive -t, but be aware that the archiving of RCS deltas is computationally expensive.
  • Files must not be copied or branched from other revisions
  • Files must not be copied or branched to other revisions
  • Files must already exist in a local depot.

To create an archive depot and archive files to it:

  1. Create a new depot with p4 depot and set the depot’s Type: to archive. Set the archive depot’s Map: to point to a filesystem for near-line or detachable storage.
  2. Mount the volume to which the archive depot is to store its files.
  3. Use p4 archive to transfer the files from a local depot to the archive depot.
  4. (Optionally), unmount the volume to which the archive files were written.

Disk space is freed up on the (presumably high-performance) storage used for your local depot, and users can no longer access the contents of the archived files, but all file history is preserved.

To restore files from an archive depot:

  1. Mount the volume on which the archive depot’s files are stored.
  2. Use the p4 verify -A command to verify files before you restore them.
  3. Use p4 restore to transfer the files from the archive depot to a local depot.
  4. (Optionally), unmount the volume to which the archive files were restored.

To purge data from an archive depot

  1. Mount the volume on which the archive depot’s files are stored.

  2. Use p4 archive -p to purge the archives of the specified files in the archive depot.

    On completion, the action for affected revisions is set to purge, and the purged revisions can no longer be restored. The data is permanently lost.

  3. (Optionally), unmount the volume from which the archive files were purged.

Reclaiming disk space by obliterating files

The purpose of a version management system is to enable your organization to maintain a history of what operations were performed on which files. The p4 obliterate command defeats this purpose; as such, it is intended only to be used to remove files that never belonged in the depot in the first place, and not as part of a normal software development process. Consider using p4 archive and p4 restore instead.

Note also that p4 obliterate is computationally expensive; obliterating files requires that the entire body of metadata be scanned per file argument. Avoid using p4 obliterate during peak usage periods.

Warning

Use p4 obliterate with caution. This is the one of only two commands in Perforce that actually remove file data. (The other command that removes file data is the archive-purging option for p4 archive)

Occasionally, users accidentally add files (or entire directory trees) to the wrong areas of the depot by means of an inadvertent branch or submit. There may also be situations that require that projects not only be removed from a depot, but the history of development work be removed with it. These are the situations in which p4 obliterate can be useful.

Perforce administrators can use p4 obliterate filename to remove all traces of a file from a depot, making the file indistinguishable from one that never existed.

Warning

Do not use operating system commands (erase, rm, and their equivalents) to remove files from the Perforce server root by hand.

By default, p4 obliterate filename does nothing; it merely reports on what it would do. To actually destroy the files, use p4 obliterate -y filename.

To destroy only one revision of a file, specify only the desired revision number on the command line. For instance, to destroy revision 5 of a file, use: 

$ p4 obliterate -y file#5

Revision ranges are also acceptable. To destroy revisions 5 through 7 of a file, use: 

$ p4 obliterate -y file#5,7

Warning

If you intend to obliterate a revision range, be certain you’ve specified it properly. If you fail to specify a revision range, all revisions of the file are obliterated.

The safest way to use p4 obliterate is to use it without the -y flag until you are certain the files and revisions are correctly specified.

Managing processes

The following sections describe the circumstances under which you might want to pause or terminate a process, and explain why you might need to do some clean-up work after a process has terminated.

Pausing, resuming, and terminating processes

To pause and resume long-running processes (such as p4 verify or p4 pull), a Perforce superuser can use the commands p4 monitor pause and p4 monitor resume. If a process on a Perforce Server consumes excessive resources, it can also be marked for termination with p4 monitor terminate.

Once marked for termination, the process is terminated by the Perforce server within 50,000 scan rows or lines of output. Only processes that have been running for at least ten seconds can be marked for termination.

Users of terminated processes are notified with the following message:

Command has been canceled, terminating request

Processes that involve the use of interactive forms (such as p4 job or p4 user) can also be marked for termination, but data entered by the user into the form is preserved. Some commands, such as p4 obliterate, cannot be terminated.

Clearing entries in the process table

Under some circumstances (for example, a Windows machine is rebooted while certain Perforce commands are running), entries may remain in the process table even after the process has terminated.

Perforce superusers can remove these erroneous entries from the process table altogether with p4 monitor clear dip, where dip is the erroneous process ID. To clear all processes from the table (running or not), use p4 monitor clear all.

Running processes removed from the process table with p4 monitor clear continue to run to completion.

Managing the database tables

Use the p4 dbstat command to display statistics on the internal state of the Perforce database. For example, 

$ p4 dbstat -a

You can also specify the name of a database file in your server’s root directory. This command is typically used in conjunction with Perforce technical support to estimate disk seeks due to sequential database scans.

Options allow you to display the following:

  • statistics for all tables
  • a page count, free pages, and percent free data for the specified table
  • a histogram showing distances between leaf pages
  • a report on the file sizes of database tables

Warning

Because p4 dbstat blocks write access to the database while it scans the tables, use this command with care. You will most often use this command when working with Perforce technical support.

Scripted client deployment on Windows

The Perforce installer supports scripted installation, enabling you to accelerate a deployment of Perforce across a large number of desktops.

Scripted installations are controlled by a configuration file that comes with the scrip table version of the Perforce installer. You can edit this file to preconfigure Perforce environment variables (such as P4PORT) for your environment, to automatically select Perforce applications in use at your site, and more.

To learn more about how to automate a deployment of Perforce, see "Automated Deployment of Perforce" in the Perforce knowledge base:

http://answers.perforce.com/articles/KB_Article/Automated-Deployment-of-Perforce

Perforce technical support personnel are available to answer any questions or concerns you have about automating your Perforce deployment.

Troubleshooting Windows installations

The following sections explain how you might resolve some Windows-related installation issues.

Resolving Windows-related instabilities

Many large sites run Perforce servers on Windows without incident. There are also sites in which a Perforce service or server installation appears to be unstable; the server dies mysteriously, the service can’t be started, and in extreme cases, the system crashes. In most of these cases, this is an indication of recent changes to the machine or a corrupted operating system.

Though not all Perforce failures are caused by OS-level problems, a number of symptoms can indicate the OS is at fault. Examples include: the system crashing, the Perforce server exiting without any error in its log and without Windows indicating that the server crashed, or the Perforce service not starting properly.

In some cases, installing third-party software after installing a service pack can overwrite critical files installed by the service pack; reinstalling your most-recently installed service pack can often correct these problems. If you’ve installed another application after your last service pack, and server stability appears affected since the installation, consider reinstalling the service pack.

Resolving issues with P4EDITOR or P4DIFF

Your Windows users might experience difficulties using the Perforce Command-Line Client (p4.exe) if they use the P4EDITOR or P4DIFF environment variables.

The reason for this is that Perforce applications sometimes use the DOS shell (cmd.exe) to start programs such as user-specified editors or diff utilities. Unfortunately, when a Windows command is run (such as a GUI-based editor like notepad.exe) from the shell, the shell doesn’t always wait for the command to complete before terminating. When this happens, the Perforce client then mistakenly behaves as if the command has finished and attempts to continue processing, often deleting the temporary files that the editor or diff utility had been using, leading to error messages about temporary files not being found, or other strange behavior.

You can get around this problem in two ways:

  • Unset the environment variable SHELL. Perforce applications under Windows use cmd.exe only when SHELL is set; otherwise they call spawn() and wait for the Windows programs to complete.

  • Set the P4EDITOR or P4DIFF variable to the name of a batch file whose contents are the command: 

    start /wait program %1 %2

    where program is the name of the editor or diff utility you want to invoke. The /wait flag instructs the system to wait for the editor or diff utility to terminate, enabling the Perforce application to behave properly.

    Some Windows editors (most notably, Wordpad) do not exhibit proper behavior, even when instructed to wait. There is presently no workaround for such programs.