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

P4 Server Administration Documentation | 2025.1

# Reclaim disk space by obliterating files

P4 Server maintains the history (metadata Information that P4 Server maintains, such as who created file revisions in the depot, whether the file is a 'lazy copy,, the current state of client workspaces, protections, groups, users, labels, streams, and branches. Metadata is stored in the server database and is separate from the 'archive files' that users submit from their client workspace into the depot.) of which operations were performed on which files.

## p4 obliterate means permanent removal

Obliterate removes both the file data and its history from the P4 Server permanently. The `p4 archive -p` command removes physical file revisions, but retains revision history. The p4 delete command does not remove revisions of the file prior to the delete operation and therefore does not recover disk space.

If certain files and their history are no longer in use, you might want to recover disk space on the central server. You can do one of the following:

- Move them into an archive depot A special depot into which versioned files (also known as archive files) can be transferred. See also 'depot'. by using the `p4 archive` command. If you later decide you want to use those files and recover their history, use the `p4 restore` command.
- Permanently delete the files by using the `p4 obliterate` command. One use case is to eliminate a submit or a branch that was created by mistake. However, the operations of `p4 obliterate` are computationally expensive.
- Permanently delete the files but retain the metadata by using the `p4 obliterate -p` command. This option recovers the disk space of the files, yet reduces the amount of time the command runs because metadata is not processed.

The p4 delete command does not remove revisions of the file prior to the delete operation and therefore does not recover disk space.

## Test before including the -y option

By default, `p4 obliterate filename` merely reports on what it would do if you include the `-y` option. For example:

    p4 obliterate -y filename.

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

    p4 obliterate -y file#5

To obliterate a range of revisions, specify the range. For example:

    p4 obliterate file#5,7

and verify what the operation would do with if the `-y` option is included. If you are sure the result is what you want, include the `-y` option:

    p4 obliterate -y file #5,7

If you do not specify a revision range, all revisions of the file are obliterated. To learn more, see Using revision ranges in the P4 CLI Reference.

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.

Avoid using `p4 obliterate` during peak usage periods because the amount of metadata to process might be large.

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

On clients of type `readonly`, `partitioned`, and `partitioned-jnl`, the p4 have command continues to list the obliterated file until the subsequent p4 sync operation. To learn more, see Client workspace types.

Your search for returned results