檔案夾大小不僅僅是所有檔案的大小總和

有一天，上頭來了一個活兒：我需要程式計算一個檔案夾的大小。

有朋友可能會覺着，這事兒忒簡單，隻需要将這個檔案夾裡的所有檔案的大小累加起來不就是檔案夾的大小了。

如果它隻是這樣簡單就好了。

有很多事情使計算檔案夾的大小變得困難，其中一些甚至會令人懷疑”檔案夾大小”這個概念是否真正存在。下面我們來看看。

重解析點(Reparse points)

關于重解析點，我們上次提到過這個。 在計算檔案夾大小時，是否要遞歸處理重解析點？這取決于你計算檔案夾大小的原因。 如果計算檔案夾大小，是為了向使用者顯示删除檔案夾後将會釋放多少磁盤空間，那麼是否這樣做，取決于将如何删除重解析點。

如果計算大小是為了準備進行複制這個檔案夾，那麼你可能會這樣做。 或者你可能不這樣做——是否應該僅僅複制重解析點？ 如果使用者沒有建立重解析點的權限怎麼辦？ 或者如果目标位置不支援重解析點？ 或者如果使用者建立副本是因為他們正在制作備份？

硬連結(Hard links)

硬連結是同一檔案的多個檔案夾條目。如果你在計算一個目錄的大小并且你發現了一個硬連結，你會計算檔案的完整大小嗎？或者你是說硬連結的每個條目都承載着檔案”權重”的一小部分？ (是以如果一個檔案有兩個硬連結，那麼每個條目都占檔案大小的一半。)

在硬連結之間劃分檔案的“權重”可以避免重複計算（或更高），以便在找到所有硬連結時，正确計算檔案的總大小。它代表了一個概念，即所有指向檔案的硬連結“分擔”檔案消耗的資源的成本。但是如果你沒有找到所有的硬連結怎麼辦？檔案大小被低估是正确的嗎？

如果你正在複制一個檔案并且你發現它有多個硬連結，你會怎麼做？複制操作是否會破壞了副本中的連結？你會嘗試重建它們嗎？如果目的地不支援硬連結怎麼辦？

壓縮檔案(Compressed files)

我說的是檔案系統壓縮，而不是像ZIP這樣的外部壓縮算法。

将目錄中檔案的大小相加時，是邏輯大小還是實體大小相加？ 如果你正在計算準備複制的大小，那麼你 可能需要邏輯大小，但如果是計算通過删除它可以釋放多少磁盤空間，那麼你可能需要實體大小。

但是，如果你正在計算複制并且複制目标支援壓縮，那麼到底要使用實體大小嗎？ 現在假設源壓縮算法和目标壓縮算法具有可比性。

稀疏檔案(Sparse files)

稀疏檔案與壓縮檔案有同樣的問題。 你想累加的是邏輯大小或實體大小？

簇舍入(Cluster rounding)

即使對于未壓縮的非稀疏檔案，你也可能需要考慮磁盤塊的大小。 包含大量小檔案的目錄需要的磁盤空間比檔案大小的總和還要多。 你想在計算中反映這一點嗎？ 如果周遊了重解析點，則簇大小也可能發生了變化。

備用資料流(Alternate data streams)

備用資料流是檔案可以占用磁盤空間的另一個地方，該空間未反映在其假定的“大小”中。

記錄開銷(Bookkeeping overhead)

總是存在與檔案存儲相關的記錄資料。 除了檔案夾條目（或多個檔案夾）之外，還需要為安全資訊以及跟蹤檔案内容所在位置的資訊配置設定空間。 對于高度碎片化的檔案，此資訊可能相當廣泛。 你想把它計入目錄的大小嗎？ 如果是這樣，怎麼做？

以上所有問題都沒有單一的答案。 你必須考慮每一個因素，将其應用到你的情況，然後決定你想走哪條路。

（而且複制樹形檔案夾的結構更可怕。你用 ACL 做什麼？你也想複制它們嗎？你保留建立日期嗎？這完全取決于你為什麼要複制它。）

總結

希望猿友看完此文後能有所啟發：檔案夾裡，除了普通的檔案，還有各種各樣，稀奇古怪的東西。

諸位，請提防提防！

最後