我想（遞歸地）將文件目錄從 WebDav 伺服器下載到某個位置。如果檔案已經存在（某處），則不應再次下載。但是資料夾結構並不相同。
有沒有簡單的方法可以做到這一點？我研究了 fdupes，但它只是用於檢測和刪除 dupes。文件非常大，開銷太大。
目標檔案系統不支援重複資料刪除。我知道cp -n（從 FUSE 安裝點）不會覆蓋現有文件，但資料夾結構不一樣。所以我有點卡住了。
答案1
從看WebDAV 的可用 Linux 用戶端，我自己首選的方法是：
使用 GVFS 或 WebDAV 檔案系統模組之一（davfs2 或 fusedav）將遠端 WebDAV 伺服器的檔案「對應」到本機檔案系統路徑。
使用內建的CP命令帶有
-n指示它“不破壞”目標中的文件的選項。請注意，某些 shell（例如dash在 Ubuntu 上）將預設執行某個builtin版本，而此內建命令可能不支援該選項。為了獲得最佳結果，請確保您正在透過執行或（取決於二進位檔案在特定係統上的位置）來執行 GNU Coreutils 版本。cp-ncp/bin/cp/usr/bin/cp
編輯：我誤讀了你原來的問題。
我認為你所說的是文件file1.txt存在於 WebDAV 伺服器中兩個不同路徑中的情況，並且內容這兩個文件的內容完全相同。由於您已經擁有該文件的副本，您不想下載該文件的第二或第三個副本，因為這會浪費頻寬？
出色地，從客戶端，這將是非常難做到的。原因如下。
你必須看看你在比較什麼確定文件是否唯一，以及要求/成本進行比較。
我假定（錯誤地）你所比較的是小路相對於 WebDAV 資料夾結構的根。進行路徑相等性比較的成本非常簡單：您只需查看兩個路徑字串（例如 ）/dir1/dir2/file1.txt，然後查看字串是否符合。如果他們這樣做，那就是重複的。如果他們不這樣做，那就不是。
您可以比較的另一件事是文件姓名，忽略小路。例如，您會認為這兩個文件重複：/dir1/dir2/file1.txt和/dir3/dir4/file1.txt嗎？好吧，如果你是僅有的比較基於姓名，那麼這些將被視為重複。但是，我們可以根據需要混合和匹配各種重複測試，以便為我們的用例進行正確的測試。
其他不太有用的比較屬性包括文件大小,屬性（也稱為元數據），文件副檔名等。多數人不會認為這兩份文件是重複的。
在我看來，您可以比較的最重要的是文件內容。不幸的是，從 WebDAV 用戶端的角度來看，在下載檔案之前您無法知道檔案內容。而對於客戶端而言，文件傳輸期間或之後文件內容可能會發生變化，在這種情況下，如果您重新下載文件，重複比較的結果將會發生變化。
比較文件內容有兩種基本方法：位元組對位元組， 和散列。逐字節是檢查重複項最「有保證」的方法，但它受到必須比較的限制整份文件，對於大量數據來說，速度非常慢。另請考慮重複檢測的基本演算法複雜度為O(n^2)，這意味著您必須將每個文件的內容與其他文件的內容進行比較，以確定它是否重複。使用加密雜湊來比較檔案可以大幅減少必須比較或傳輸的資料量，但缺點是兩個檔案實際上可以被比較的可能性非常小。不同的但具有相同的雜湊值——稱為哈希衝突。
但話又說回來，從客戶透視，不可能知道什麼文件內容，甚至是它的哈希值，除非您：
- 從伺服器下載檔案；或者
- 說服伺服器在本地為您計算哈希值，然後下載哈希值。
在前一種情況下，您下載文件是為了確定它是否是重複的，以避免下載該文件，所以顯然您不能這樣做 - 您正在浪費您試圖避免的頻寬只是為了進行比較！
在後一種情況下，你可能會有所收穫。非常大的檔案的 SHA1 雜湊值只有幾個字節，只佔大檔案大小的一小部分。下載所有檔案的雜湊值並進行O(n^2)比較是相當實用的哈希值以確定要下載哪個文件。不過，如果在進行這些比較時伺服器上的檔案資料發生變化，您仍然會遇到競爭條件問題，因此如果同步對您很重要，您需要確保考慮同步。
所以，結論：
- 如果如果您沒有對 WebDAV 伺服器的完全軟體控制，並且無法更改其配置，那麼在確定您是否已經擁有相同副本時，您幾乎不走運 (tm)文件內容它們儲存在伺服器上的多個檔案中，除非伺服器管理員已經為伺服器上的每個文件提供了某種雜湊文件，如果您可以依賴雜湊值，這可能會讓您取得一定程度的成功。
- 如果你做對 WebDAV 伺服器有完全的軟體控制，並且有能力的要變更其配置，您可能需要編寫一個腳本或程式（或使用現有的程式）來建立一個帶有副檔名的雜湊文件，例如
.sha1sum與 WebDAV 伺服器託管的每個文件位於同一目錄中。假設您的檔案大小超過幾千字節，這可以讓您僅下載雜湊值並進行比較，與檔案大小相比，頻寬成本相對適中。