我在perforce depot的文件结构中有很多文件，即使以管理员身份登录，我也无法通过perforce clients p4命令行或p4v gui查看。
我试图通过p4文件和p4 filelog命令找到任何元数据，但它总是返回：
＆＃34; - 没有这样的文件。＆＃34;
此外，我运行了p4 verify和p4 dbverify，看看我们是否在服务器上有任何错误，但是它们没有返回任何错误。似乎没有文件的记录，除了它们占用了HDD的空间。
我目前的理论是，他们来自失败的提交，但我不知道如何获得权力以确认文件，以便我可以删除它们。
背景资料：
答案 0 :(得分：1)
服务器的软件仓库文件系统中的内容与元数据中定义的软件仓库的实际结构之间不一定存在一对一的映射 - 软件仓库修订版只编写一次，即使它们也不会移动或重复从客户的角度来看，移动或重复。因此，您绝对不应该假设因为depot文件系统中的给定文件与库文件路径不对应，它实际上并没有为其他现有文件提供底层存储（特别是如果您在某些文件系统中使用了obliterate）文件的分支，同时保留其他文件的完整性 - 剩余的存档文件可能是您留下的文件的内容。
也就是说，如您所建议的那样，档案也可能成为“孤儿”的一部分。如果涉及的空间量很小，我建议不要担心它（孤立的文件不会在碰撞方面造成任何问题），但如果能够清理它们很重要，那么最好的办法是使用“snap -n”以确保没有任何这些依赖项，然后手动删除它们（为了安全起见，我会保留它们的备份，至少在你运行下一次验证之前确保没有重要的失踪了）。运行：
p4 snap -n //... //depot/path/to/mystery/file
这说“在depot / // / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /如果你运行没有-n的命令，它实际上会通过生成物理副本来破坏这些依赖关系（如果你担心空间，不要这样做，因为你最终会得到N个冗余的存档副本）。
p4 snap -n的反转（即“此库文件的存档在哪里生效？”）为p4 fstat -Oc //depot/file。