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.