Perforce Public Knowledge Base - Protections and Obliterate
Reset Search
 

 

Article

Protections and Obliterate

« Go Back

Information

 
Problem

A super user attempts to obliterate a file and gets "no records to delete". However, p4 files command shows that there are still file revisions remaining for that file. Why do I still see revisions for a file I obliterated?


Solution

The problem is with the protection table not granting super permission on the file(s) in question. Check your protections table to confirm that you have not inadvertently removed access to the files in question. One common mistake is adding protections lines below the "super" user line. Always be certain that your super users are granted access in the last lines of the protections table to avoid this problem.

User's of Perforce server 2006.1 and later can use "p4 protects" to determine the permission on a specific file or path. For example, a super user is attempting to obliterate "//depot/bar/foo.c", and receives the "no records to delete" error. He runs the command:

p4 protects //depot/bar/foo.c

write user * * -//...
super group super_users * //...
write group all_users * -//...
list group non_devs * //depot/....c

These protections lock out all users, and then re-adds access based on group. Here the super user account was added to the "all_users" and "non_devs" group. The first protection is exclusionary -- it's locking out all access to all users. Since this line comes after the "super_users" group, we've accidentally removed all access, and then re-added access to source code (.c) files, but only at "list" access.

Moving the super user group to be the last line fixes the problem.

Related Links
Administering Perforce: Protections
Perforce System Administrator's Guide

Feedback

 

Was this article helpful?


   

Feedback

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

Characters Remaining: 255