Perforce客戶端缺少硬盤上的文件

我在perforce軟件倉庫的文件結構中有很多文件，即使以管理員身份登錄時，我也無法使用perforce客戶端p4命令行或p4v gui查看。Perforce客戶端缺少硬盤上的文件

我試圖尋找到P4文件和P4 filelog命令的任何元數據，我可以，但它始終返回：「 - 沒有這樣的文件（S）」

此外，我已經運行p4驗證和p4 dbverify，看看我們有沒有在服務器上的任何錯誤，但他們沒有返回任何錯誤。似乎沒有文件的記錄，除了它們在HDD上佔用空間這一事實。

我目前的理論是他們來自失敗的提交，但我不知道如何讓perforce來確認這些文件，以便我可以將它們抹去。

背景信息：

這是一個簡單的Perforce設置只用主車廠和老項目檔案庫。（神祕文件在主要軟件倉庫中）
服務器版本是：P4D/NTX64/2012.2/551823（2012/11/09）。

來源

2017-09-15 Philip Warren

你說你無法通過Perforce客戶端看到它們。到底你在打字什麼？你使用倉庫路徑還是本地路徑？你確定你的Perforce客戶端的視圖配置正確嗎？ – jamesdlin

你需要提供更多的細節。選擇一個或兩個具體的例子，並提供所有的細節。你對基本概念似乎很困惑。例如，你談論的是「客戶端丟失的文件」，但是你會談論很多關於試圖「刪除」或「驗證」這些文件的文件，這些文件隻影響**服務器**上的文件，而不是**客戶**。 –

@jamesdlin我正在使用軟件倉庫路徑，例如'p4文件// depot/path/to/files/...' –

不一定有什麼之間是在服務器的庫文件系統，在元數據中定義的庫的實際結構的一個一對一的映射 - 庫修訂被寫入一次，不移動或複製即使從客戶的角度來看它們被移動或複製。所以你絕對不應該這樣假設，因爲軟件倉庫文件系統中的給定文件與軟件倉庫文件路徑不對應，它實際上並沒有爲其他現有文件提供底層存儲（尤其是如果你已經使用某些文件同時保留其他檔案文件的分支 - 剩餘的檔案文件可能是您留下的其中一個的內容）。

也就是說，根據您的建議，檔案也可能成爲「孤兒」作爲失敗提交的一部分。如果涉及的空間很小，我建議不要擔心它（孤立的文件不會造成碰撞方面的任何問題），但是如果清理它們很重要，最好的方法是使用「snap -n」，以確保沒有任何這些依賴關係，然後手動刪除它們（爲了安全起見，我至少要保留它們的備份，直到你運行了下一次驗證，以確保沒有任何重要的事情發生失蹤了）。兼營：

p4 snap -n //... //depot/path/to/mystery/file

這是說「給我看在車廠（// ......）與//庫存檔依賴性/路徑/到/懸疑/文件的任何地方文件」。如果在沒有-n的情況下運行該命令，它實際上會通過製作物理副本來破壞這些依賴關係（如果擔心空間，則不要這樣做，因爲最終會得到N個冗餘副本）。

p4 snap -n（即「此存儲庫文件的存檔位於何處？」）的倒數是p4 fstat -Oc //depot/file。

來源

2017-09-15 14:22:15

Hi Sam，這看起來很有希望。 Yest這個抽象的文件是爲什麼我非常謹慎的從硬盤刪除文件。我可以按名稱搜索文件，但我看不到確保文件未重命名的方法。不幸的是，這是由於硬盤驅動器包含的空間不足導致本次調查，而這些神祕文件佔三TB以上硬盤的三分之一。因此，保留這些文件不是一種選擇。 –

我一回到辦公室就會嘗試。有趣的是，我在查看正確的文檔時，似乎並未將p4 snap列在[2012.2的命令參考]（https://www.perforce.com/perforce/r12.2/manuals/cmdref/index.html）中？ –

檢查'p4 help undoc'。 –

Perforce客戶端缺少硬盤上的文件

回答

相關問題