不是文件，不是文件夾，而是從另一個分區到 /bin 的硬連結（？） - 害怕刪除

我的文件系統上有一個 not-quite-folder not-quite-file。它是一個執行 Ubuntu 18.04.4 LTS 的 AWS EC2 實例。

我有一個每晚執行的腳本，它使用 Robo 拾取文件（/ebsvol/dead-drop/sync）並將其移動到（/ebsvol/dead-drop/sync），而 Robo 又使用 Symfony 的 Filesystem rename() 方法（https://symfony.com/doc/current/components/filesystem.html#rename）。

 const CANARY_PATH = '/ebsvol/dead-drop/sync';
 const CANARY_WORKING_PATH = '/ebsvol/dead-drop/~sync';
...
 $this->taskFilesystemStack()
   ->rename(self::CANARY_PATH, self::CANARY_WORKING_PATH)
   ->run();

腳本或這段程式碼出了點問題，但這並不是我來這裡的真正原因。結果和清理就是我在這裡的原因。:)

結果是創建了 ~sync “文件”，但它實際上是…到 /bin 的硬連結？這就是事情變得可疑的地方。我的ls -ial樣子是這樣的：

3276803 -rw-rw-r--  1 configbot configbot  125 Jul  4 00:30 '~sync'

所以它只是一個文本文件，所以讓我們試試 cat…

$ cat ~sync
cat: /bin: Is a directory 

嗯，好的。

$ cd ~sync

…將我的提示更改為 /bin，然後執行 ls，它肯定是 bin。順便說一句，ls -ial在我的根卷上顯示 /bin 是 iNode 12。

這在我過去曾經發生過一次，我只是這樣做了rm -rf ~sync，它淹沒了我的整個伺服器，我不得不重建。所以我試圖避免這種情況。

如何在不丟棄 /bin 的情況下擺脫這個奇怪的 ~sync 文件/文件夾/符號連結/硬連結？

一些附加資訊：

• /ebsvol是一個單獨的 EBS 卷，而不是/（即單獨的硬碟驅動器/分區！）
• 我認為如果它以某種奇怪的方式成為硬連結，rm ~sync可能會起作用。但它不會顯示相同的 iNode 編號嗎？
• 在嘗試任何操作之前，我將拍攝兩個卷的快照。:)

如果您打算使用 bash 之類的 shell 訪問文件，那麼命名以波浪號開頭的文件是一個非常糟糕的主意。原因是它將波浪號解釋為您想要訪問使用者的主目錄。

因此，bash（和其他 shell）展開~到目前使用者的主目錄，並展開~sync到名為 sync 的使用者的主目錄。

事實證明，您的 Ubuntu 系統有一個名為的系統使用者sync，其主目錄為/bin. 因此，當您嘗試~sync從 shell 訪問時，它會將其擴展到使用者的主目錄，並且您開始收到奇怪的消息。當你執行rm -rf ~sync效果時rm -rf /bin，這幾乎會破壞系統。

如果你想訪問文件本身，可以引用它，或者在它前面加上一些東西，比如它的路徑：

$ cat ./~sync

您還應該重新編寫程式碼，使其不會創建以波浪號開頭的文件名。這將為您和未來的您節省很多麻煩。

引用自：https://serverfault.com/questions/1024000