關(guān)于騰訊QQ中轉(zhuǎn)站數(shù)據(jù)安全的討論，見前一篇博文， http://blog.csdn.net/Jhzyz/archive/2009/09/17/4564723.aspx

剛才，我發(fā)現(xiàn)還有另外一種錯(cuò)誤，以壓縮文件為例，就是出現(xiàn)“不可預(yù)見的檔案文件末端”，這和壓縮包內(nèi)文件CRC error不同，壓縮文件完全被破壞掉了。

騰訊在設(shè)計(jì)QQ中轉(zhuǎn)站時(shí)，為了節(jié)約硬盤空間和上傳帶寬，如果在上傳時(shí)，發(fā)現(xiàn)有MD5碼相同的文件，會(huì)自動(dòng)引用，就是所謂的快速上傳。

問題來了，這也是我要說的Bug，在服務(wù)器上文件被損壞時(shí)，最原始的上傳者刪掉自己的中轉(zhuǎn)站文件重新上傳，如果這個(gè)文件分享給朋友，朋友轉(zhuǎn)入中轉(zhuǎn)站保存，這個(gè)文件仍然會(huì)在服務(wù)器上。

此時(shí)，當(dāng)服務(wù)器的文件被損壞后，最初的上傳者再次上傳正確的完好文件時(shí)，會(huì)被系統(tǒng)“快速上傳”完成，造成服務(wù)器上的錯(cuò)誤文件始終不能被更新！如圖：

要解決這個(gè)Bug，第一要保證服務(wù)器上的文件絕對(duì)不能出錯(cuò)，但這是不可能的?。。∷裕仨氁谖募畔⒅斜４娴?個(gè)上傳者的ID，允許第1個(gè)上傳者完全上傳更新服務(wù)器上的文件！

看來QQ中轉(zhuǎn)站在解決管理和技術(shù)問題之前，要少用了，重點(diǎn)轉(zhuǎn)向Raysource、Namipan和CTdisk等網(wǎng)盤了。

續(xù)：

看到有朋友回復(fù)提出意見，把解釋補(bǔ)充到這兒。 (希望騰訊的相關(guān)技術(shù)或管理人員能看到)

-------------- 但是這兩個(gè)文件應(yīng)該是不一樣的啊 md5值也是不同的哦 你那個(gè)估計(jì)是下載的時(shí)候，比如網(wǎng)絡(luò)差，沒有下載完整重新下載下呢？
csc已經(jīng)不同，md5怎么可能相同呢？
------------------------------------------------
這就是騰訊設(shè)計(jì)上的問題，最初上傳文件它在服務(wù)器上的MD5碼是當(dāng)時(shí)保存的，文件被破壞后，再次上傳時(shí)并不是重新生成MD5碼，而是用重新上傳的文件，檢測(cè)最初的MD5碼，認(rèn)為相同就被快速上傳。
所以騰訊要改變這個(gè)Bug，另一個(gè)選擇就是上傳時(shí)在服務(wù)器實(shí)時(shí)檢測(cè)已存在文件的MD5碼，但這會(huì)占用太多的服務(wù)器資料，這是開發(fā)者不愿意看到的。

騰訊QQ中轉(zhuǎn)站數(shù)據(jù)安全堪憂（續(xù)+Bug報(bào)告）