Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Reference | 2025.1

# p4 verify

Verify that the P4 Server archives (depot files) are intact (complete and without corruption).

## Syntax

    p4 [g-opts] verify [-u | -v | -z] [-m max -q -s -X -b batchsize] file[revRange] ...
    p4 [g-opts] verify [-t [-r]] [ --only BAD | MISSING ] [-U | -A ]
                       [-z -m max -q -s -X -b batchsize] file[revRange] ...
    p4 [g-opts] verify -S [-v | -t [-r] [ --only BAD | MISSING ]
                       [-m max -q -X -b batchsize] FileSpec[@=shelvedChange] ...
    p4 [g-opts] verify -U [-u | -v | -z] [-m max -q -s -X -b batchsize] unloadFile ...
    p4 [g-opts] verify -A [-u | -v | -z] [-m max -q -s -X -b batchsize] archiveFile ...
    p4 [g-opts] verify -R [-m max -q -s -X -b N] [-v | --only BAD | MISSING] archiveFile ...
    p4 [g-opts] verify -Z [ -q ] file

Syntax conventions

## Description

For each revision of the specified depot files, `p4 verify` reports the revision-specific information and an MD5 digest (fingerprint) of the revision’s contents.

The verification process involves opening the depot file (sometimes called the depot archive file), reading it, and verifying that its digest matches the expected value.

- If the file can’t be opened, `p4 verify` reports `MISSING!` at the end of the line.
- If the file can be opened, but does not have the expected contents, `p4 verify` reports `BAD!` at the end of the line.

Reports with BAD! or MISSING! file revisions are directed to stderr. Therefore, if you have the command in a script, you need to capture both stderr and stdout. The exception to this rule is when you use the -s option of Global options. Running p4 -s verify //depot/main/p4/... results in all output going to stdout, with each line indicating whether it is an Info or Error message. See the final example in Examples.

If invoked without arguments, `p4 verify` computes and displays the MD5 digest of each revision.

Syntax variants offer the following choices:

- Verify a given set of file revisions.
- Verify a given set of shelved file revisions.
- Verify file revisions in the unload depot.
- Verify file revisions in the archive depot A special depot into which versioned files (also known as archive files) can be transferred. See also 'depot'.. Archive depots can be a solution for storing infrequently-accessed files. To learn more, see Reclaiming disk space by archiving files in P4 Server Administration Documentation.

We recommend that you regularly verify the integrity of your depot files. To learn more, see backup-recovery-ensuring-integrity.html in the P4 Server Administration Documentation.

### Verifying shelved files

The verification of shelved files lets you know whether your shelved archives have been lost or damaged.

If a shelf is local to a specific edge server, you must issue the `p4 verify -S` command on the edge server where the shelf was created. If the shelf was promoted, run the `p4 verify -S` on the commit server.

You can also run the `p4 verify -S -t` command on a replica to request re-transfer of a shelved archive that is missing or bad. Re-transferring a shelved archive from the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. only works for shelved archives that are present on the target server, that is, a shelf that was originally created on the target server or promoted from an edge server.

### Verifying archived files

The verification of archived files lets you know whether your archived files have been damaged. It is a good practice to run a command like the following before you restore files with the `p4 restore` command.

    p4 verify -A //archive/depot/mysource/...

If `p4 verify` returns errors, contact Perforce Technical Support.

## Options

`-A archivefiles` | It is possible for files in the archive depot to become corrupted over time. This option allows you to verify these files before you restore them with the `p4 restore` command. archivefiles specifies a file, a list of files, or set of files to verify. For example:
    //archive/depot/..../source
`-R` | Repair mode to help with disaster recovery. If an archive file is missing, this mode will check if an identical file is shelved. If so, a copy of the shelved file replaces the missing archive file.
`-b batchsize` | By default, `p4 verify` processes files in batches of 10,000 files at a time. You can change this batch size with the `-b batchsize` option, where batchsize represents an integer. To disable batching, specify `-b 0`. If the `-z` option is specified, the `-b` option is ignored and all options are processed in a single batch.
`-m max` | Limit `p4 verify` to `max` number of revisions. Use this option with the `-u` option to compute and save digests for a limited number of revisions in each invocation of the `p4 verify` command. Depending on the FileSpec, p4 verify -m 10 FileSpec might list 10 files, 10 versions of a single file, or a combination of files and file versions.
`-q` | Run quietly and report only errors from mismatched digests or unreproducible revisions.
`-s` | Verify file size as well as digest. The `-v` implies the `-s` option.
`-S` | Verify shelved files. If you specify this option, the only valid revision specifier is `@=change`, specifying a single shelf. Use file patterns to restrict verification to a specific set of shelved files. In a multi-server installation, this command should be run on the edge server where the shelf was created. If the shelf has been promoted, this command can also be run on the commit server.
`-t` | When used on a replica, any damaged or missing revisions are scheduled for transfer from the `P4TARGET` server. When used on a commit server, the damaged or missing revisions are scheduled for transfer from the first replica that confirms it has a valid archive file for that revision. The -t option cannot be used with the -v, -Z or -u options. This option also works on a replica with `lbr.replication=cache`. In replicated environments, `p4 verify -t` reports `BAD!` or `MISSING!` files with `(transfer scheduled)` at the end of the line. For performance, avoid using p4 verify -t against a replica to seed a replica archive. Instead, follow this two-step process: (1) Use an operating system command to copy the versioned files from the commit server to the edge server. Files and directories can be moved using rsync, tar, ftp, a network copy, or any other method that preserves the files as they were on the original server. (2) Use p4 verify -t to pull over the deltas (what's changed since the OS copy), which is a smaller subset of data.
-r | For use only with the -t option: prevents revisions of the text type (contained within an RCS file) from being transferred.
--only | The --only filter option, where either BAD or MISSING is the filter. The MISSING filter reports only missing revisions, and checksums are not calculated. The --only option can be combined with the -t option to restrict the revisions to be transferred. The --only option cannot be used with the -v, -Z or -u options.
`-u` | Store the filesize and MD5 digest of each file in the P4 Server database if no filesize and/or digest has been previously stored. Subsequent uses of `p4 verify` will compare the computed version against this stored version.
`-U unloadfile` | Verify files in the unload depot. See `p4 unload` for details.
`-v` | Store the MD5 digest of each file in the P4 Server database, even if there’s already a digest stored for that file, overwriting the existing digest. (The `-v` option is used only to update the saved digests of archive files Versioned files that users submitted to a depot. that have been deliberately altered outside of P4 Server control by a P4 Server system administrator.) The `-v` and `-u` options are mutually exclusive.
`-X` | Skip files of filetype `+X` (for which the service runs an `archive` trigger.)
`-z` | Optimizes performance by skipping revisions that have already been computed in the current pass. This option speeds verifications for files that exist via lazy copies. The resulting output might report a lazy copy revision if it is the first revision in the sort order to access a common archive file. This option cannot be used with the `-v` or `-u` options.
-Z | Specifies that the digest and file length check use the storage table as opposed to the revision table. This is generally faster because the lazy copied files are only checked one time. The output displays the reference count instead of the action and change fields. The file argument is different because a lazy copied depot file is not selectable. For example, consider file //x/x with a lazy copy at the path //y/y. Calling p4 verify -Z //y/... does not verify any files because there is no storage record that matches the //y path. However, without the -Z option, p4 verify //y/... uses the revision table to find and check the //x/x file. The -Z option can be combined solely with the -q option.
`g-opts` | See Global options.

## Usage notes

Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required
--- | --- | ---
Yes | Yes | `admin` available to an operator user

## Examples

`p4 verify -S //depot/main/p4/...` | Verifies all shelved files matching the specified path.
`p4 verify -q -S //...@=1023548` | Verifies the shelved files in shelf `1023548` only.
`p4 verify -q //...#head,#head` | Verifies only the head revision of all files in the depot, reporting only on files with problems.
p4 -s verify //depot/gz | Verifies the specified path, but with the -s option of Global options, instead of errors going to sterr, each line of output goes to stdout and indicates whether it is an Info or Error message:
    info: //depot/gz#2 - edit change 44 (text+m) 8F5EB715075F3EC462C3A1
    error: //depot/gz#1 - add change 81 (text) 8F5EB715075F3EC462C3A1 MISSING!

## Related commands

To get information about how you can specify revisions. | `p4 help revisions`

Your search for returned results