(cp is to cat AS mv is to ?) mv 多個文件到一個文件而不是 cat * rm *
對於這個問題中的所有內容，都假設系統只有一個磁碟和文件系統。（我們沒有寫入不同的分區、磁碟或文件系統）
我正在研究一個將
cat非常大的 .MTS 文件放入一個巨大的 .MTS 文件的項目。這需要讀取每個小文件並將它們寫入一個新的更大文件，然後刪除小文件。對於這麼大的文件，這需要很長時間。我的理解-
cp比mv因為cp讀取文件並將其寫入磁碟上的不同位置需要更長的時間。mv另一方面，不復製或移動文件。mv刪除對文件的引用並在新位置創建一個新文件。例如mv /tmp/foo /tmp/bar，將文件保留在磁碟上並刪除指向/tmp/foo磁碟上文件的引用並添加指向磁碟上文件的新引用/tmp/bar。問題：
cat就像cp因為它將文件複製到新位置。有了這麼大的文件，完成後不需要較小的文件，是否有類似的東西cat使用mv而不是cp？理論（我可能錯了）
文件分散儲存在驅動器周圍已經很常見。例如，一個 2GB 的文件可能有幾個較小的塊儲存在驅動器的不同部分。這樣，當 5K 文件被刪除時，它可以被 20MB 文件的一部分覆蓋。如果我們將 2GB 文件留在原處並僅引用所有部分，似乎我們可以
cat foo/* >> bar/bigfile.MTS; rm foo/*在很短的時間內產生相同的效果。如果沒有什麼可以做到這一點，這是一個壞主意，誰能給我舉個例子說明為什麼？鼓勵用分散的文件塊破壞磁碟是不是很糟糕？
像這樣的工具存在的最大障礙是，除非每個文件的大小（最後一個除外）被連接起來完全可以被塊大小整除（我對這裡的正確術語有點不確定），否則你最終會得到最終文件中連接文件之間的垃圾數據“間隙”。
這是因為文件數據通常儲存在文件系統上具有特定大小的塊中，因此使用 32 字節塊儲存在文件系統上的 618 字節文件將佔用 618 / 32 = 19.3125 個塊，即 19 個完整塊，大約額外方塊的 1/3。
假設您想像這樣組合兩個文件而不考慮我的障礙，您只需將“新文件”指向第一個文件的塊，再加上第二個文件的塊，對嗎？
使用這種幼稚的方法，您最終會得到一個包含 40 個塊的文件，其中第 20 塊是 1/3 可感知的和 2/3 垃圾，而第 21 塊開始第二個文件的數據。
對於某些文件格式，您可能可以對文件頭進行一些巧妙的計算和操作，以基本上告訴將使用該文件的應用程序跳過垃圾部分，但這更像是一種創可貼解決方案而不是適當的解決方案。