Perforce Public Knowledge Base - How to Handle p4 verify BAD Errors
Reset Search
 

 

Article

How to Handle p4 verify BAD Errors

« Go Back

Information

 
Problem

How do you eliminate "BAD" errors from p4 verify output.


Solution
The "BAD" error is reported when the MD5 digest of a file revision stored in the Perforce database differs from the one calculated by the p4 verify command. This error indicates that the file revision might be corrupted.

To check if a file is truly corrupted, someone familiar with that file needs to check the content of the affected file revision and, whenever possible, diff it against a previous revision or workspace file. If the file is indeed corrupted, you will need to restore the associated depot file from a backup.

Otherwise you can recalculate the file digest by running the following command:

p4 verify -v <file>

Possible reasons for "BAD" errors

There are several reasons for the digest of a file to change, thus generating a "BAD" error:

  1. Hardware failure

    Versioned files can become corrupted when a disk is failing (bad blocks, defective disk controller, and so on). Because checking files as they are being written can adversely effect performance, Perforce does not confirm file data written to disk.

    Note: RCS files are completely rewritten every time a new non-compressed revision is added.  Hardware failure can therefore introduce errors in older file revisions.
     
  2. Network issues

    Perforce uses TCP/IP to transfer files over the network and relies on the TCP checksum rather than calculating the digest of the received files. TCP is a reliable point-to-point protocol, however, file corruption can be introduced by network nodes (like a networking proxy), and will not be detected on the server end. Running p4 verify regularly can help to detect such problems. If data integrity is a concern, a digest check of submitted files can be enforced by the use of a content trigger.
     
  3. Moving or otherwise modifying versioned files

    If the archive files are moved or modified outside of Perforce, it is possible to accidentally introduce changes that can alter a file's revision checksum digest. This will trigger "BAD!" errors. One common scenario involves text files that employ RCS keyword expansion.  Re-locating a versioned file tree may change keyword expansion values.  Keyword expansion values on "ktext" files can also change if the time zone of the server changes.

    If you note that all of the file revisions marked as "BAD" are of file type "ktext", and you can confirm that the files are not truly damaged or corrupted, use p4 verify -v on the specific file revisions reporting the problem.  This will cause Perforce to recompute the MD5 digest values for these revisions.

Known issues with p4 verify

In addition to the items in the previous section, there are several known issues in previous versions of Perforce that can produce erroneous "BAD" errors:

#118635 (Job #22297)
    "p4 submit" could submit a branched file with a bad archive
    entry if the source revision of the branched file is purged 
    before the submit is completed. This has been fixed.

#105715 (Job #21893)
    Submitting a new version of a file with a pre-2003.2 client
    would result in the wrong digest value being set. This has
    been fixed.

#104039 (Job #21693)
    Integrating a ktext file to a text file resulted in bad
    checksums when running 'p4 verify' using the initial
    2006.1 server. Fixed. 

#57034 (Job #13096)
    After "p4 verify -u" had been used against the revisions in a
    spec depot, all new revisions would be reported as "BAD" by
    "p4 verify". This was caused by the server incorrectly reusing
    the checksum of the previous revision. This fault has now been

    fixed.  

#59362 (Job #13495)
    Integrating a ktext file to a non-ktext file could result in
    a bad digest being copied to the target of a lazy copy. The
    problem would be reported by a subsequent verify command.

All of the above bugs have been fixed in the latest version of the Perforce Server. Upgrading your Perforce Server will remedy these issues within the server.  It will not change the MD5 hash values stored for file revisions.  After upgrading, you may need to run p4 verify -v on these file revisions to correct any remaining "BAD" errors being reported.  You should only run this command on the specific file revisions which need correction. Do not run it on the entire depot.

Note: If there is any question regarding whether your verify output is reporting a file as "BAD", please contact Perforce Support.

Related Links

Feedback

 

Was this article helpful?


   

Feedback

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

Characters Remaining: 255