面向中小機構(gòu)的文件管理系統(tǒng)的設(shè)計與實現(xiàn)

郭彩云　王會進　龍　舜　黎欣健

(暨南大學(xué)信息科學(xué)技術(shù)學(xué)院　廣東 廣州 510632)

?

面向中小機構(gòu)的文件管理系統(tǒng)的設(shè)計與實現(xiàn)

郭彩云王會進龍舜黎欣健

(暨南大學(xué)信息科學(xué)技術(shù)學(xué)院廣東 廣州 510632)

針對目前中小機構(gòu)對文件管理的需求，分析當(dāng)前網(wǎng)盤存在的問題，設(shè)計研發(fā)一款操作便捷、管理有效的輕量級文件管理系統(tǒng)。該系統(tǒng)采用標(biāo)簽技術(shù)對文件進行分類和檢索，通過虛擬文件層和SHA-1算法實現(xiàn)了文件去重和資源回收，利用分布式的版本控制思想有效地解決了多用戶情況下文件版本控制問題，保證了用戶訪問數(shù)據(jù)的一致性，實現(xiàn)了網(wǎng)絡(luò)文件存儲、文檔協(xié)同修改、多用戶共享文件等功能。實際應(yīng)用情況表明，系統(tǒng)能夠有效地管理和共享文件，實現(xiàn)多用戶協(xié)同工作，對重復(fù)文件能夠自動檢測和刪除，大大提高了存儲資源和網(wǎng)絡(luò)資源的利用率，降低了資源管理復(fù)雜度。

文件管理系統(tǒng)標(biāo)簽版本控制虛擬文件層

0　引　言

信息技術(shù)的發(fā)展不僅推動了操作流程的自動化，也使機構(gòu)和個人積累了大量的電子文檔。寬帶網(wǎng)絡(luò)的普及使得文件的下載和分享變得快速而簡便，但隨之而來的問題是文件數(shù)量以指數(shù)級增長，文件重復(fù)率顯著增加。據(jù)IDC報告顯示[1,2]，2005年到2020年期間，數(shù)據(jù)總量將從130 EB增長到40 000 EB。如何有效地管理這些海量數(shù)據(jù)，保護數(shù)據(jù)資產(chǎn)的安全和可靠，以及如何快速、便捷的實現(xiàn)數(shù)據(jù)轉(zhuǎn)移、存儲和獲取等，已經(jīng)成為當(dāng)前階段急需解決的現(xiàn)實問題[3]。

對中小型機構(gòu)來說，文件管理是其信息管理的核心部分，低效的文件管理將會導(dǎo)致工作效率低下，存儲資源浪費，大大削減其競爭力。目前，許多機構(gòu)對文件管理不再局限于文件的存儲與分類查詢，對文檔的及時更新共享和協(xié)同修改合并也提出了更多更高的要求，對于數(shù)據(jù)存儲的實時性、安全性、可靠性和移動性要求也越來越高。傳統(tǒng)的文件管理系統(tǒng)已經(jīng)不能很好地適應(yīng)用戶的需求。

隨著云計算云存儲的發(fā)展，已經(jīng)有很多網(wǎng)盤系統(tǒng)實現(xiàn)了文件的存儲和管理[4-6]。Dropbox[7]是Dropbox公司提供的在線存儲服務(wù)，用戶可以存儲并共享文件和文件夾。Google Drive[8]是Google推出的在線同步存儲服務(wù)，結(jié)合了文檔在線編輯功能。OneDrive[9]是微軟推出的網(wǎng)絡(luò)硬盤及云服務(wù)，允許用戶通過Microsoft Account來限制不同用戶訪問文件的權(quán)限。這些服務(wù)在一定程度上可以幫助機構(gòu)和個人管理文件，實現(xiàn)文件存儲、同步和分享等功能，但不能很好地支持多用戶對同一文件的修改與合并，實現(xiàn)協(xié)同工作。而且出于對隱私數(shù)據(jù)的安全性考慮，很多組織機構(gòu)和個人也難以接受將一些機密的文件存儲在公共云存儲服務(wù)中。此外，從經(jīng)濟角度考慮，網(wǎng)盤價格昂貴，對中小機構(gòu)并非合適的選擇。

為此，本文在綜合分析中小機構(gòu)需求和現(xiàn)有網(wǎng)盤技術(shù)的基礎(chǔ)上，開發(fā)了一款輕量級的、高效實用的網(wǎng)絡(luò)文件管理系統(tǒng)。該系統(tǒng)利用標(biāo)簽對文件進行多維度分類，使文件檢索更加便捷高效；設(shè)計的輕量級虛擬文件層實現(xiàn)了文件的存儲和排重，大大降低了文件的冗余程度，節(jié)省了存儲空間；借鑒Git分布式的版本控制思想解決了在多用戶文件共享中的版本沖突、版本更新等版本控制問題。

1　總體設(shè)計

系統(tǒng)整體框架如圖1所示，該系統(tǒng)以基礎(chǔ)網(wǎng)絡(luò)存儲為核心，包含三個主要的功能模塊，分別為標(biāo)簽?zāi)K、用戶模塊、共享模塊。

圖1　系統(tǒng)整體框架

(1) 基礎(chǔ)網(wǎng)絡(luò)存儲模塊用于提供基礎(chǔ)的文件操作，提供全文檢索功能，還負責(zé)維護文件的歷史版本，允許查詢、刪除或回滾到某個歷史版本。

(2) 標(biāo)簽?zāi)K允許用戶為文件添加任意數(shù)量的自定義或系統(tǒng)推薦的標(biāo)簽。系統(tǒng)會根據(jù)標(biāo)簽使用頻次和標(biāo)簽標(biāo)注的文件數(shù)量進行加權(quán)排序得出標(biāo)簽顯示列表。系統(tǒng)提供標(biāo)簽檢索文件的功能。

(3) 用戶模塊提供用戶個人信息的基本維護和對外公開訪問的個人頁面。用戶可以查看公開共享的文件信息及下載次數(shù)，還提供關(guān)注的功能。關(guān)注某用戶后可以收到該用戶新增共享文件的通知，用戶互相關(guān)注可以實現(xiàn)以小組形式的文件共享與版本維護，實現(xiàn)靈活的共享。

(4) 共享模塊提供用戶公開共享和私密共享兩種方式。前者由系統(tǒng)為用戶創(chuàng)建公開共享鏈接并發(fā)送至用戶選擇的社交網(wǎng)絡(luò)中；后者用戶可為共享添加密碼。在共享版本管理中，用戶可以指定文件的分享對象，并設(shè)定是否接受更新推送，接受共享的用戶可以對共享文件做任意的修改，并使用系統(tǒng)中的更新推送功能把版本更新推送給原文件的分享者，而分享者可以查看該版本更新，并選擇是否接受新版本覆蓋自己的當(dāng)前版本。

該系統(tǒng)以個人和小團隊為服務(wù)對象、面向中小組織機構(gòu)，致力于對大量文件的存儲管理進行優(yōu)化，通過對流程和技術(shù)的改進，解決了多用戶對于文件分享以及版本維護等問題。與現(xiàn)有網(wǎng)盤系統(tǒng)相比，具有如下優(yōu)勢：

(1) 能有效地支持對文件的多分類管理，從而實現(xiàn)文件多分支檢索。

(2) 支持多人共同維護文件版本，從而實現(xiàn)多人協(xié)同工作，提高工作效率。

(3) 不僅可以把文件公開分享到社交網(wǎng)絡(luò)，還實現(xiàn)了小組內(nèi)指定訪問權(quán)限式的共享。

2　關(guān)鍵技術(shù)

2.1標(biāo)簽分類思想

傳統(tǒng)的文件分類使用單一的維度對資源進行分類，文件訪問路徑是唯一確定的，整個目錄是一個樹型結(jié)構(gòu)。如果想要一個文件同屬于多個類別，那么就需要拷貝該資源到相應(yīng)的目錄下，但這樣造成了存儲資源的浪費。

為了解決上述問題，受Gmail郵箱系統(tǒng)標(biāo)簽式郵件管理和國內(nèi)外關(guān)于標(biāo)簽的最新研究思想的啟發(fā)，將標(biāo)簽式分類思想引入了文件管理系統(tǒng)中。通過標(biāo)簽對資源進行分類，每個資源可以添加任意數(shù)量的標(biāo)簽，每個標(biāo)簽也能被用在任意數(shù)量的資源上，資源和標(biāo)簽的關(guān)聯(lián)是多對多的關(guān)系。文件訪問路徑不再唯一，用戶可以通過多條路徑找到自己想要的資源。例如可以給某電影資源加上“電影”、“愛情”、“喜劇”等標(biāo)簽。用戶就可以通過該電影的全部標(biāo)簽的任意非空子集作為條件檢索到它。這種標(biāo)簽分類的思想可以滿足對同一個資源多維度分類的需求，而無需額外創(chuàng)建資源的拷貝占用不必要的空間。

2.2虛擬文件層的設(shè)計

傳統(tǒng)的計算機文件系統(tǒng)利用文件和樹形目錄的抽象邏輯概念來代替硬盤和光盤等物理設(shè)備的數(shù)據(jù)塊概念，用戶不必關(guān)心數(shù)據(jù)實際存儲地址，只需記住它所屬的目錄和文件名即可。

然而，這一做法在實際應(yīng)用中表現(xiàn)出明顯的不足。例如：用戶可以給同一個文件起完全不同的文件名稱，這會導(dǎo)致一個文件出現(xiàn)多個副本，造成存儲資源的浪費和文件檢索項過多而引發(fā)的查詢效率低下。有研究表明[10,11]，系統(tǒng)所保存的數(shù)據(jù)存在大量冗余，并隨著時間的推移，冗余程度會變得越來越嚴(yán)重，系統(tǒng)可能要額外花費超過10倍的存儲空間和管理成本。因此，減少冗余文件是降低系統(tǒng)存儲和管理成本的必經(jīng)途徑。

為了解決上述問題，我們提出并實現(xiàn)了一種輕量級的虛擬文件層(如圖2所示)，它包括文件信息層、文件索引層和文件系統(tǒng)層。MD5和SHA-1是兩種常用的根據(jù)文件內(nèi)容產(chǎn)生哈希值進行指紋識別以檢測重復(fù)文件的方法[12]。對于MD5的128位哈希值，在數(shù)據(jù)量為1018B情況下，發(fā)生單次沖突的概率為10-9。而對于160位的SHA-1哈希值，發(fā)生單次沖突的概率為7×10-18。兩種方法不僅抗沖突性較好，而且在普通硬件條件下計算速度非?？?，加州大學(xué)研究表明[13]采用SHA-1及MD5生成哈希索引的處理速度分別為83 MB/s和227 MB/s。

圖2　虛擬文件層示意圖

本系統(tǒng)選用SHA-1生成文件的哈希值，然后將文件索引與所有已存儲的哈希值進行比較，如果檢測到相同的索引值，則僅將該文件信息指向重復(fù)文件的索引而不進行實際存儲，否則存儲新的文件。該方法計算速度快，重復(fù)數(shù)據(jù)刪除吞吐量高。

在上傳文件過程中，本系統(tǒng)首先會計算該文件的SHA-1值，并在索引層中檢索該SHA-1值。如果沒有找到，則新文件會上傳至服務(wù)器中，引用計數(shù)加1，并在文件信息層中添加一條屬于該用戶的文件條目記錄，這條記錄包含文件的上傳時間、文件名和對應(yīng)的文件哈希值等內(nèi)容。如果找到，就直接將文件的引用計數(shù)加1，并為上傳用戶添加新的文件條目記錄，但指向原來已經(jīng)存在的文件。具體如流程1所述：

流程1用戶上傳文件

Function UploadFile(HttpPostedFile uploadfile,User user1){

//使用SHA-1計算文件的哈希值

Hashvalue=SHA-1(uploadfile);

//在索引層中檢索是否已存在該哈希值

If (Check(Hashvalue) ==false) {

//false表示不存在

int count=0;

//引用計數(shù)

Add uploadfile to file server;

//將文件上傳至服務(wù)器中

Add Hashvalue to index layer;

//將哈希值加入到索引層中

//為文件上傳者增加一條文件條目記錄

Create a record for the user1;

count ++;

//引用計數(shù)加1

}else{

//true表示文件已經(jīng)存在，不再上傳

//為文件上傳者增加一條文件條目記錄

Create a record for the user1;

count ++;

//引用計數(shù)加1

}

}

當(dāng)用戶執(zhí)行刪除文件操作時，系統(tǒng)首先會檢測用戶是否有權(quán)限。如果有，則執(zhí)行刪除操作，如果沒有，就提醒用戶無權(quán)刪除該文件。在刪除文件過程中，由于其他用戶也可能指向該文件，系統(tǒng)不應(yīng)直接把底層對應(yīng)的文件刪除。因此，系統(tǒng)首先會計算該文件的引用計數(shù)，如果引用計數(shù)不為零表明仍有文件信息層記錄引用該底層文件。執(zhí)行刪除操作時，就將引用計數(shù)減1，并刪除該用戶指向該文件的文件條目；當(dāng)引用計數(shù)為零時，就表示已經(jīng)沒有引用記錄，即可進行資源回收。具體流程如下所述：

流程2用戶刪除文件

Function DeleteFile(HttpDeleteFile deletefile,User user2){

//檢測用戶是否有刪除文件的權(quán)限

If(Check(deletefile,user2) ==true){

//true表示用戶有權(quán)限

If(deletefile.count>0){

//文件引用計數(shù)大于0

Deletefile.count --;

//引用計數(shù)減1

//刪除user2的文件條目記錄

Delete the record of user2；

}

If(deletefile.count ==0){

//文件無用戶引用

//存儲資源回收，刪除索引層中該文件的哈希值

Delete deletefile,recycling storage resource;

Delete deletefile.Hashvalue from index layer;

}

}else{

printf(“無權(quán)刪除該文件”);

//提示用戶無權(quán)限刪除文件

}

}

2.3版本控制

版本控制VC(Version Control)[14-16]是用于追蹤文件狀態(tài)變化的軟件管理方法，常見于軟件開發(fā)、數(shù)據(jù)同步等應(yīng)用環(huán)境中。目前，分布式版本控制系統(tǒng)被廣泛運用于軟件開發(fā)中，它不僅有利于源文件的更新和共享，而且客戶端可以完整備份服務(wù)器中的數(shù)據(jù)，當(dāng)服務(wù)器發(fā)生故障時，也可以從其他節(jié)點恢復(fù)數(shù)據(jù)。

系統(tǒng)借鑒Git[17]的分布式版本控制，實現(xiàn)文件追蹤和多用戶協(xié)同工作，具體流程如圖3所示。

圖3　文件版本控制流程圖

它的基本思想是將文件管理員的工作區(qū)作為中央倉庫，允許具有下載和修改文件權(quán)限的用戶獲取文件，并在自己的工作區(qū)修改文件。用戶可將修改后的文件提交給中央倉庫。中央倉庫將以棧的形式保存每個用戶提交后的文件版本信息。

在提交修改文件的過程中，如果用戶基于中央倉庫的文件版本沒有更新，用戶可以直接提交修改后的文件。如果有更新，那么用戶就需要將其他用戶的修改合并到自己的修改文件中，并產(chǎn)生一個新的版本上傳至中央倉庫。

2.4共享文件版本維護

共享文件在有了多個版本后會帶來管理上的困難。其中一個問題是允許用戶共享的是文件的當(dāng)前版本還是所有歷史版本。觀察目前已有網(wǎng)盤系統(tǒng)，共享文件大多是創(chuàng)建共享時文件的當(dāng)前版本。接收共享的用戶一般直接下載文件，或?qū)⑽募D(zhuǎn)存到自己的網(wǎng)盤空間再做修改，但是卻無法跟原有用戶或原文件做互動。有部分網(wǎng)盤系統(tǒng)也有簡單的私密群組共享功能，利用簡單的添加訪問密碼的方式來實現(xiàn)。但總的來說，并不能很好地處理多用戶和多個文件歷史版本時的文件版本維護問題。

為解決這一問題，本系統(tǒng)借鑒了GitHub在處理多用戶協(xié)同開發(fā)以及代碼版本控制時，使用的一種稱為“fork-pull-request”的處理方法[18]。當(dāng)用戶A在Github上共享了一個代碼倉庫，用戶B想要對其中的代碼進行修改，必須通過“Fork”創(chuàng)建一份完整的代碼倉庫拷貝到自己的存儲空間。當(dāng)用戶B對在自己存儲空間中的那一份代碼拷貝做出修改后，可以向倉庫的原作者用戶A發(fā)起“Pull - Request”。用戶A接收到“Pull - Request”之后可以查看用戶B做出的改動，用戶A可以選擇是否接收該改動，并且對于文本格式的代碼文件，通?？梢杂上到y(tǒng)自動合并修改，合并修改后文件會往后推進一個版本。

受上述做法的啟發(fā)，在文件共享的過程中，系統(tǒng)的文件版本控制業(yè)務(wù)流程如圖4所示。

圖4　多用戶文件分享中的版本控制流程圖

(1) 用戶A選擇共享某個文件的版本1給用戶B，系統(tǒng)會以郵件方式發(fā)送推送消息通知用戶B接收文件，用戶B也可通過登錄系統(tǒng)查看用戶A發(fā)送的共享信息；

(2) 用戶A在共享后對文件進行修改產(chǎn)生了版本2，而用戶B將文件版本1轉(zhuǎn)存到自己的存儲空間后進行修改，產(chǎn)生了版本3和版本4；

(3) 如果用戶B選擇把自己的修改更新推送給原用戶A，系統(tǒng)將會通過推送消息通知用戶A接收該版本的更新，用戶A可以查看推送過來的新版本，并確認是否接收該版本；

(4) 用戶A可以根據(jù)接收的用戶B的修改，將修改合并到版本2中，產(chǎn)生新的文件版本5，此時系統(tǒng)會以消息推送通知用戶B，如果用戶B確認接收文件的最新版本5，則兩個用戶間的文件版本就同步了。

歸納來說，我們允許其他用戶創(chuàng)建文件的分支版本到自己的存儲空間，修改之后允許用戶向原文件提供者發(fā)送請求更新，這樣就可以較好地處理在多用戶文件共享過程中出現(xiàn)的版本沖突、版本更新等版本控制問題。

3　系統(tǒng)實現(xiàn)與測試

基于上述的研究和設(shè)計，我們使用PHP 5.3.5語言在Windows 7 Ultimate環(huán)境下實現(xiàn)了該系統(tǒng)，后臺數(shù)據(jù)庫使用Mysql 5.1，應(yīng)用服務(wù)器為Apache 2.2.25。前臺開發(fā)框架為Bootstrap v3.1.1，JQuery 1.10.2，后臺開發(fā)框架為ThinkPHP 3.1.3。整體界面如圖5所示，支持文件上傳，標(biāo)簽編輯，文件搜索，用戶信息維護等功能，主體部分用來顯示文件列表，右擊文件列表中的文件，就能彈出與該文件相關(guān)的菜單，包括編輯標(biāo)簽、重命名、刪除文件、查看和編輯歷史版本、分享文件的功能。

圖5　個人文件管理界面

為了衡量系統(tǒng)整體的主觀滿意度，邀請了40個用戶對本系統(tǒng)進行了為期一個月的試用和評估，他們對本系統(tǒng)進行了評分，評分等級為1～5分，評分越高表示越滿意，從圖6中可以看出用戶對本系統(tǒng)整體評價還是比較高的，具有一定的實用價值。

圖6　用戶對系統(tǒng)整體評價

4　結(jié)　語

本文在基于個人和中小機構(gòu)對文件存儲管理的需求上，研究和分析了現(xiàn)有一些網(wǎng)盤所存在的問題，設(shè)計并實現(xiàn)了一款適合中小機構(gòu)的基于標(biāo)簽的文件存儲管理系統(tǒng)。該系統(tǒng)能夠滿足用戶對大量文件管理的需求，可以自由地上傳下載文件，能夠利用標(biāo)簽對文件進行分類存儲，能有效地對文件進行跟蹤和版本控制，用戶之間可以通過互相共享文件并以小組的方式共同維護文件的版本。

在接下來的工作中，將從以下幾個方面繼續(xù)完善該系統(tǒng)：

(1) 利用分享文件的下載熱度發(fā)展個性化推薦。系統(tǒng)可以根據(jù)用戶常用標(biāo)簽、常分享的文件的標(biāo)簽等給用戶推薦文件。

(2) 社會化協(xié)同標(biāo)簽編輯，可以通過分析其他用戶對相似文件添加的標(biāo)簽來做標(biāo)簽推薦，也允許用戶邀請其他用戶來協(xié)同編輯某個文件的標(biāo)簽。

(3) 搭建文件共享型社交網(wǎng)絡(luò)，利用文件分享來聚集有相近興趣點的人群，提供更加便捷的用戶通信交流及文件互通的方式，加強用戶之間的互動。

[1] Gantz J,Reinsel D.The digital universe in 2020:Big data,bigger digital shadows,and biggest growth in the far east[OL].2012.http://isilon.org/collateral/analyst-reports/idc-the-digital-universe-in-2020.pdf.

[2] Gantz J,Reinsel D.The digital universe decade-are you ready?[OL].2010.http://www.emc.com/collateral/analyst-reports/idc-digital-universe-are-you-ready.pdf.

[3] 楊揚,賈君君,李為衛(wèi).基于ASP.NET的網(wǎng)絡(luò)文件管理系統(tǒng)開發(fā)應(yīng)用研究[J].計算機科學(xué),2011,38(B10):222-224.

[4] 王洋.淺談網(wǎng)絡(luò)硬盤的應(yīng)用及其優(yōu)勢以及缺點[J].智能計算機與應(yīng)用,2009(4):60-61.

[5] 王妙婭.基于網(wǎng)盤的網(wǎng)絡(luò)資源共享模式特點及問題[J].圖書館學(xué)研究,2013(3):38-41.

[6] 傅穎勛,羅圣美,舒繼武.一種云存儲環(huán)境下的安全網(wǎng)盤系統(tǒng)[J].軟件學(xué)報,2014(8):1831-1843.

[7] Wikipedia.Dropbox_(service)[EB/OL].[2015-5-27].http://en.wikipedia.org/wiki/Dropbox_(service).

[8] Solano E T,Casado N S,Marí J H G.Google Drive[J].Pilar Sanmartín Pita,2014:69-79.

[9] Wikipedia.Microsoft_OneDrive[EB/OL].[2015-4-28].http://en.wikipedia.org/wiki/Microsoft_OneDrive.

[10] McKnight J,Asaro T,Babineau B.Digital archiving:end-user survey and market forecast 2006-2010[EB/OL].[2006-03-15].http://www.enterprisestrategygroup.com/2006/03/.

[11] 敖莉,舒繼武,李明強.重復(fù)數(shù)據(jù)刪除技術(shù)[J].軟件學(xué)報,2010,21(5):916-929.

[12] 尚穎丹.面向文件級重復(fù)數(shù)據(jù)刪除的稀疏索引技術(shù)[D].國防科學(xué)技術(shù)大學(xué),2012.

[13] You L L,Pollack K T,Long D D E.Deep Store:An archival storage system architecture[C]//Data Engineering,2005.ICDE 2005.Proceedings.21st International Conference on.IEEE,2005:804-815.

[14] 張蓮.基于云存儲的云同步系統(tǒng)的設(shè)計與實現(xiàn)[D].中國科學(xué)技術(shù)大學(xué),2014.

[15] 陽萬安,李彥.通用版本控制系統(tǒng)的研究和設(shè)計[J].計算機工程,2008,34(12):283-284.[16] 張蓮,李京,劉煒清.云同步系統(tǒng)中采用增量存儲的版本控制技術(shù)研究[J].小型微型計算機系統(tǒng),2015,36(3):427-432.

[17] Loeliger J,Mccullough M.Version Control with Git[J].Oreilly Media,2012:365-382.

[18] Dabbish L,Stuart C,Tsay J,et al.Social coding in GitHub:transparency and collaboration in an open software repository[C]//In CSCW.2012:1277-1286.

DESIGN AND IMPLEMENTATION OF DOCUMENT MANAGEMENT SYSTEM FOR SMALL AND MEDIUM-SIZED INSTITUTIONS

Guo CaiyunWang HuijinLong ShunLi Xinjian

(College of Information Science and Technology,Jinan University,Guangzhou 510632,Guangdong,China)

Targeted at the requirement of medium and small-sized institutions on documents management at present, we analyse current problems of network disks, and present in this paper a light-weighted document management system which is convenient in operation and effective in management. The system classifies and retrieves documents with tagging technique, and achieves files deduplication and resources recovery through virtual file layer and SHA-1 algorithm. It uses the idea of distributed version control to effectively solve the problem of document version control among multiple users, guarantees the consistency of users data access, and realises the functions of network files storage, document collaborative amendment, and multi-user document sharing, etc. Actual application situations of the system demonstrate that it can effectively manage and share files, achieves multi-user cooperative work, and can automatically detect and delete duplicate files, these greatly increase the utilisation of storage and network resources, and reduce the complexity of resource management as well.

Document management systemTagVersion controlVirtual file layer

2015-05-29。廣州市科技計劃項目(2013Y2-00066)。郭彩云，碩士生，主研領(lǐng)域：網(wǎng)絡(luò)技術(shù)與數(shù)據(jù)庫。王會進，教授。龍舜，副教授。黎欣健，本科。

TP317.1

A

10.3969/j.issn.1000-386x.2016.09.017