有時人們會刪除不應該刪除的文件，長時間運行的進程仍然會打開文件，並且透過 cat 恢復資料/proc/<pid>/fd/N還不夠好。如果您可以透過執行 ln 的一些神奇選項來「撤銷」刪除，這將讓您重新連結到 inode 編號（透過 lsof 恢復），那就太棒了。
我找不到任何 Linux 工具來做到這一點，至少透過粗略的谷歌搜尋。
你有什麼，伺服器故障？
編輯1：從中捕獲文件的原因/proc/<pid>/fd/N還不夠好，因為仍然打開文件的進程仍在寫入它。刪除將從檔案系統命名空間中刪除對 inode 的引用。我想要的是一種重新建立參考的方法。
EDIT2：「debugfs ln」可以工作，但風險太高，因為它會取得原始檔案系統資料。恢復的文件也非常不一致。連結計數為零，我無法添加連結。我的情況更糟，因為我只能使用它/proc/<pid>/fd/N來存取資料而不會損壞我的檔案系統。
答案1
如果您可以透過執行 ln 的一些神奇選項來「撤銷」刪除，這將讓您重新連結到 inode 編號（透過 lsof 恢復），那就太棒了。
這種奇妙的東西是ln在v8.0(GNU/coreutils) 附有導致首先取消引用-L|--logical的選項。那麼一個簡單的ln/proc/<pid>/fd/<handle>
ln -L /proc/<pid>/fd/<handle> /path/to/deleted/file
足以重新連結已刪除的檔案。
答案2
聽起來你已經明白了很多，所以我不再贅述。有多種方法可以找到 inode，通常可以捕獲並重定向 STDOUT。您可以使用debugfs。在以下位置執行此命令：
ln <$INODE> FILENAME
確保您有檔案系統的備份。之後您可能需要執行 fsck。我成功地測試了這一點，索引節點仍在寫入，並且它確實可以創建指向取消引用的索引節點的新硬連結。
如果該文件與 ext3 中未開啟的文件取消鏈接，則資料將遺失。我不確定這是否正確，但我的大部分資料復原經驗都是使用 ext2 進行的。來自 ext3 常見問題：
Q：如何從 ext3 分割區復原（取消刪除）已刪除的檔案？事實上，你不能！開發人員之一安德烈亞斯·迪爾格 (Andreas Dilger) 對此說道：
為了確保ext3 可以在崩潰後安全地恢復取消鏈接，它實際上將inode 中的塊指針清零，而ext2 只是在塊位圖中將這些塊標記為未使用，並將inode 標記為“已刪除”並離開該區塊單獨指點。
您唯一的希望是「grep」尋找已刪除的檔案部分，並希望得到最好的結果。
這個問題中也有相關資訊：
答案3
正如您所看到的debugfs 方式並沒有真正起作用，最好的情況是您的檔案將在重新啟動後自動刪除（由於日誌），最糟糕的情況是您可以丟棄檔案系統，從而導致「重新啟動死亡週期」。正確的解決方案 (TM) 是在 VFS 層級執行取消刪除（這也具有與幾乎所有當前 Linux 檔案系統一起使用的額外好處）。系統呼叫方式（flink）在LKML中每次出現都被擊落，所以最好的方式是透過模組+ioctl。
實現這種方法並且具有相當小且乾淨的程式碼的專案是 fdlink (https://github.com/pkt/fdlink.git對於使用 ubuntu maverick 核心測試的版本）。有了它，在插入模組（sudo insmod flink_dev.ko）後，您只需執行“./flinkapp /proc//fd/X /my/link/path”，它就會完全按照您的要求進行操作。
您也可以使用vfs-undelete.sourceforge.net 的前向移植版本，它也可以工作（並且還可以自動重新連結到原始名稱），但fdlink 的程式碼更簡單，而且工作得也很好，所以這是我的偏好。
答案4
我不知道如何做你想要的，但我會做的是：
- 從另一個進程開啟檔案RO
- 等待原進程退出
- 將資料從開啟的 FD 複製到文件
顯然，這並不理想，但有可能。另一個選擇是使用 debugfs（使用link命令），但這在生產機器上有點可怕！