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
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:
- 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.
- 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.
- Modifying the Versioned Files Outside of Perforce
Any event which alters the contents of an archive file outside of Perforce is likely to cause BAD errors. This included editing archive files directly in your favourite editor.
- Old ktext (text+k) files
Files with RCS keyword expansion may cause BAD errors.
Sometimes this is the result of a version control conversion or from very old files.
Changing the timezone in which the Perforce server is started will also cause BAD errors in text files that employ RCS keyword expansion. RCS keywords are expanded on the server when the file revision is required, for example, during a sync operation. If the server's timezone differs from the timezone in effect when then file revision was submitted the files content will effectively have changed so a BAD error will be reported.
If 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
#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
#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