Perforce Public Knowledge Base - P4D "-xx" Flag
Downloads Blog Company Integrations Careers Contact Try Free
Menu Search
Reset Search



P4D "-xx" Flag

« Go Back


Warning: If you suspect Perforce database corruption and don't have a current checkpoint and journal files you should call or e-mail Perforce support immediately. Attempting to address the issue on your own can result in the corruption or loss of your data.

The "-xx" flag performs a consistency check between Perforce database table pairs, and attempts to produce a journal file that repairs any inconsistencies. The basic syntax is:

p4d case_flags -xx [db.table_1 db.table_2]

The case_flags option may not be needed, but can be important if your server is running in some cross platform and non-default case sensitivity configurations.  If you know how the original server "p4d" was invoked, check to see what case case sensitivity flags were used, and use that to help you decide if the depot is case sensitive or not.

Once you know if the depot is Case Sensitive, and what platform you are running p4d on now, you can use the following table to determine what case_flags to use:
Case Sensitive Depot?Current Platform and Filesystemcase_flags
YesMacintosh - Standard FilesystemDon't Use this combination
NoMacintosh - Standard Filesystemnone
YesMacintosh - Case Sensitive Filesystem-C0
NoMacintosh - Case Sensitive Filesystem-C1
YesWindows - Any FilesystemDon't Use this combination
NoWindows - Any Filesystemnone
NoLinux - Any Filesystem-C1

This command  perform referential integrity checking between table pairs and is usually used with the "-xv" command. If any inconsistencies are found, a special journal file is created, "jnl.fix", which contains a set of delete ("@dv@") and create ("@pv@") journal records.  Do not attempt to replay the "jnl.fix" file into your depot without consulting Perforce Technical Support.

When run without arguments, all table pairs are checked. If valid table pairs are given, only those tables are checked.  Invalid pairs are ignored quietly (no error is generated). Valid pairs display messages in the format:

Check db.table_1/db.table_2...

Valid table pairs are (as of 2017.1):

  • db.change/db.desc
  • db.fix/db.job
  • db.have/db.rev
  • db.integed/db.rev (twice because integration records are bi-directional)
  • db.resolve/db.working
  • db.working/db.have
  • db.working/db.rev
  • db.rev/db.revcx
  • db.working/db.locks
  • db.change/db.changex
  • db.rev/db.revhx
  • db.rev/db.revdx
  • db.resolvex/db.workingx
  • db.workingx/db.change
  • db.workingx/db.revsh

If any errors are found you, will see a message in the format:

Perforce server error:
        db.table_1/db.table_2 inconsistencies found.

For example:

> p4d -xx
Check db.change/db.desc...
Check db.fix/db.job...
Check db.have/db.rev...
Perforce server error:
	db.have/db.rev inconsistencies found.
Check db.integed/db.rev...
Check db.integed/db.rev...
Check db.resolve/db.working...
Check db.working/db.have...
Check db.working/db.rev...
Check db.rev/db.revcx...
Check db.working/db.locks...
Check db.change/db.changex...
Check db.rev/db.revhx...
Check db.rev/db.revdx...
Check db.resolvex/db.workingx...
Check db.workingx/db.change...
Check db.workingx/db.revsh...

Running p4d -xx locks tables in pairs as their referential integrity is being validated. This will block other commands so you probably want to schedule production downtime and shut down the server before running p4d -xx. Note however, that the command is read-only so you can stop it at any time with CTRL+c should you need to put the server back into production.


  • If no error messages are generated, the jnl.fix file will still be created. Prior to version 2012.1, this file will be zero bytes in size. An empty jnl.fix file can be erased at any time. Beginning with Perforce Server version 2012.1, an "empty" jnl.fix file will contain still contain two lines of metadata starting with an @nx@ and an @ex@ record. If these are the only two lines present, the file can be safely deleted.
  • Repeated invocations of the p4d -xx command will overwrite the jnl.fix file. Accordingly, if a non-empty jnl.fix was generated previously, it is recommended to save the previously generated file to a new name for reference, prior to invoking p4d -xx again.
  • The checks performed by p4d -xx are in addition to those performed by taking a checkpoint.
Related Links



Was this article helpful?



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

Characters Remaining: 255