電影/系列文件跟蹤或水印C＃

-1

我試圖開發的軟件的某些部分是文件跟蹤器。它跟蹤電影或系列文件（500 MB - 50 GB）。它必須跟蹤即使是電影/系列文件跟蹤或水印C＃

移動相同的磁盤
移動到另一個磁盤上的文件
移動網絡共享
更名爲
等

如果發生這種情況，它必須掃描所有的設備並重新編制「丟失」文件。但接縫比我想象的要困難得多。我多次嘗試了這麼多事，但沒有什麼接縫可以做得很好。我試過幾件事情，但他們總是缺乏ATLEAST一個標準：

FileSystemID - >只有一個磁盤上的工作
文件名 - >上的重命名
FielSize不工作 - >漂亮的不穩定
哈希 - >極其昂貴。不適用於低功率機器
Windows-API-Code-Pack - >我永遠無法保存。有些時候有時會出現異常，但它不起作用。接縫處於開發狀態
水印文件 - >接縫可能會在文件的末尾附加一個GUID，但它會更改文件，並且接縫對於非常大的文件來說速度很慢。

如果他們結合起來，它會解決問題，但在代碼和計算時間上相當複雜。我用水印製作的最佳體驗。也許有一種方法可以更好地追加和讀取GUID？但對我來說，它接近大文件真的很慢。

我真的需要一種快速而一致地識別文件的方法。標識符不能丟失，並在NTFS和分機號上工作。我希望爲我的複雜問題提供一些不錯的提示。謝謝:)

來源

2016-12-04 Stefm

由於這是相當普遍的面試問題，你應該能夠找到很多關於它的討論......必應搜索，如果你還可以使用它 - https://www.bing.com/search？q = google + interview + question + file + duplicate + hashing –

如果你唯一感興趣的是更快地附加到文件 - 比這是相同的http://stackoverflow.com/questions/2398418/how-append-data- （請注意，附加到文件*不會解決您在更改文件時描述的問題，並且可能會破壞文件格式） –

我不確定當涉及到文件大小時，「unstable」是什麼意思。

我的建議是使用文件的大小以字節爲索引的第一個手段（因爲它是由操作系統緩存，並允許極快的重複檢查）

之後，您可以使用一個FileStream不讀完整的文件，但文件和哈希的前1 MB（或任何你選擇的）。這應該相當快。

這應該會給你一個相當準確的文件跟蹤，儘管不完美。但是如果你想要完美的話，那麼整個文件的哈希是必須的。

在NTFS中，您可以使用「Alternate Streams」將ID附加到文件中，但這些也可以由用戶自由添加/刪除，並且在離開NTFS空間時會丟失。

來源

2016-12-04 18:40:07 Martin

我認爲這是不穩定的，因爲它可能是另一個具有相同大小的文件。我不知道這個值會發生什麼，它將被移動到另一個磁盤，也可能是其他塊大小。即使在大型服務器上，幾TB數據的全散列成本也很高，因爲如果丟失大部分文件，您必須重新散列大多數文件。我從來沒有聽說過有關「alternatice Streams」的內容。這聽起來很有趣 – Stefm

除非特別要求這些值，否則文件大小（至少在Windows中）不受羣集大小或壓縮的影響。所以文件大小應該是內容字節的實際數量，因此非常準確。如果你添加部分散列，你應該很好恕我直言 – Martin

電影/系列文件跟蹤或水印C＃

回答

相關問題