Perforce Public Knowledge Base - Permanently Removing Files and associated Metadata
× PRODUCTS SOLUTIONS CUSTOMERS LEARN SUPPORT
Downloads Company Partners Careers Contact Free Trials
Menu Search
Perforce
Reset Search
 

 

Article

Permanently Removing Files and associated Metadata

« Go Back

Information

 
Problem

I need to permanently eliminate some data currently under Perforce control. I'm absolutely certain that I will never need to use or access this data again.

 

Solution

Perforce server installations consist of archive files and metadata. Archive files reflect the actual contents of files stored on the Perforce server. Archive files are generally stored as either RCS format files or compressed binaries, and are located in the Perforce server root (for example, $P4ROOT/depot/). Archive files are distinguishable by their ",v" suffix and as gzipped files in ",d" directories (for example, $P4ROOT/depot/foo,d/1.1.gz). Perforce metadata is a catalog of all transactions on the Perforce archive files and other program related data. The perforce metadata is stored in the db.* files found in $P4ROOT.

Although one of the primary functions of Perforce is to permanently preserve all history and relationships via archive files and metadata, on occasion you may have good reason to permanently eliminate some history and relationships by eliminating some archive files and metadata. The command p4 obliterate makes this possible.
 

CAUTION! p4 obliterate should be used with extreme caution. Unlike p4 delete, which preserves archive files and metadata, p4 obliterate PERMANENTLY eliminates both archive files and metadata. This means that once you use p4 obliterate to remove data, that data can never be recovered. Therefore, you should only use p4 obliterate if you are absolutely certain that you will never again need to use or access the data to be obliterated. If there's a chance that you might ever need to use or access the data again, you should use p4 delete.
 

The p4 obliterate command permanently removes files from the depot and requires administrator privilege to run.

The basic syntax of the command is:

$ p4 obliterate file[revRange] ...

 


By default, p4 obliterate runs in Preview Mode, merely reporting what it would do:

$ p4 obliterate //depot/JAM/main/src/regexp.c
Would delete 1 client 5 label 4 integration 6 revision record(s).
This was report mode.  Use -y to remove files.If you would like more information 


More information on the files to remove can be seen by the p4 files command.  For example, to be sure you are removing a changelist, run

$ p4 files @12345,@12345
$ p4 obliterate @12345,@1234


To actually perform the requested obliterate, add the -y option:

$ p4 obliterate -y //depot/JAM/main/src/regexp.c
Deleted 1 client 5 label 4 integration 6 revision record(s).


The p4 obliterate command requires at least one file pattern as an argument. If you specify a single revision, only that revision of the file is obliterated.

Example:

$ p4 obliterate //depot/Jam/main/src/regexp#2


If you specify a revision range all the revisions in that range are obliterated. 

Example:

$ p4 obliterate //depot/JAM/main/src/regexp.c#3,5


Note: Beware of using a scripting language that interprets a # sign as a comment!  You don't want numbers after the pound sign to be ignored.

All information about the file is deleted from the server, including the files' revisions, the files' metadata, and any entries in any labels or client workspace records that refer directly to that file. Copies of files in client workspaces are not deleted, but are no longer under Perforce control.


Obliterate Hanging

If the p4 obliterate command hangs, try the following:

1.  Run p4 fstat to find the versioned file:
 
          $ p4 fstat -Oc //<depot>/<dir>/<file>/...



2. From the lbrFile line, go to the Perforce server and look under the corresponding directory under the Perforce server root and find the ,v file

          <file>,v


3. Rename this ,v file

          $ mv <file>,v <file>,v.orig


4. Attempt the obliterate the version again. Ignore the error RCS non-existant revision 1.<number> to delete!



Obliterate and Performance

Using p4 obliterate on large scale obliterates on large or very busy servers can adversely impact performance. So starting with release 2012.1. p4 obliterate has three flags that can improve performance. From p4 help obliterate:
  • The '-b' flag restricts files in the argument range to those that are branched and are both the first revision and the head revision...
  • The '-a' flag skips the archive search and removal phase.  This phase of obliterate can take a very long time for sites with big archive maps (db.archmap)...
  • The '-h' flag instructs obliterate not to search db.have for all possible matching records to delete.  Usually, db.have is one of the largest tables in a repository and consequently this search takes a long time...

For more information on these flags, see the Perforce Command Reference, specifically, p4 obliterate, or use the command p4 help obliterate.

 

Obliterate and "Lazy Copies"

After branching a file from one area of the depot into another, a "lazy copy" is performed. A lazy copy is a method used by Perforce to make internal copies of files without duplicating file content in the depot. Lazy copies minimize the consumption of disk space by storing references to the original file instead of copies of the file.
 

2006.2 and Later Behavior 

Starting with release 2006.2:

  • p4 obliterate uses the db.archmap (archive map) table instead of the db.archive table to check for archive files that are referenced by lazy copies.
     
  • When p4 obliterate finds archive files that are referenced by lazy copies, the archive files are not deleted from the server.
     
  • Lazy copies are no longer replaced with real files because they are not adversely affected by removal of the original archive files they were branched from.
     
  • New revisions are stored in the archive files keyed to the filename and pending changelist number, instead of filename and revision number. Old revisions in the archive files are not renumbered.
 
Notes for Perforce Administrators

This is a server change that is not visible to Perforce end users, but there are a few things that are important for Perforce administrators to know.

  • You might notice the change in storage if examining archive file contents, because new revisions are stored in the archive files keyed to the filename and pending changelist number.
     
  • After running 2006.2 p4 obliterate, you might notice that some of the corresponding archive files are not deleted from the server. Do not remove these files. The remaining archive files are the sources of lazy copies.
     
  • If you must delete the remaining archive files from the server, use the undocumented p4 snap command. The p4 snap command scans the specified file revisions for any revision whose archive file (revision contents) is a lazy copy (virtual target). For each of these files the archive contents are copied into that revision's archive namespace. Be aware that the p4 snap replaces lazy copies with real files for every specified file revision, which can cause the overall size of the database of archive files to increase. See p4 help snap for additional details and contact Perforce Technical Support if you need more help.
 

2005.1 Through 2006.1 Behavior

For releases 2005.1 through 2006.1, p4 obliterate behavior is as follows:

  • p4 obliterate uses the db.archive table to check for archive files that are referenced by lazy copies.
     
  • When p4 obliterate finds archive files that are referenced by lazy copies, the lazy copies are replaced with real files before the archive files are deleted from the server.
     
  • Lazy copies are replaced with real files to ensure they are not adversely affected by the removal of the original archive files from which they were branched.
 

2004.2 and Earlier Behavior

For releases 2004.2 and earlier, p4 obliterate behavior is as follows:

  • p4 obliterate scans the db.rev table to check for archive files that are referenced by lazy copies.
     
  • When p4 obliterate finds archive files that are referenced by lazy copies, the lazy copies are replaced with real files before the archive files are deleted from the server.
     
  • Lazy copies are replaced with real files to ensure they are not adversely affected by the removal of the original archive files they were branched from.
Related Links

Feedback

 

Was this article helpful?


   

Feedback

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

Characters Remaining: 255