一種檔案目錄結構的設想
fishcat 原創
1.現存盤案系統的一點不足
我們知道，作業系統誕生以來，檔案系統經歷了好多型別，其中使用最為廣泛的就是dos的fat和windows的fat32以及windownt的ntfs,這些檔案系統乙個共同的特點，就是檔案完全的層次性，即訪問某一檔案時，需要從根目錄開始一層一層的進入，從使用者的角度來說這是很不方便的。如果乙個使用者建立的個file1.txt放在c:/windows/profiles/all users/下，那他就得開啟這麼多層的目錄才能訪問到他的檔案。從現代作業系統所要求的易於操作這一點來說就沒有合乎要求。其實，作業系統的設計者沒有理由強求使用者記住他存放某個檔案的路徑，大部分的工作應該讓計算機來完成。特別是對名稱唯一的檔案，系統應該做到只要使用者給出了檔名就能馬上給使用者提交這個檔案。這個現實的需要對現存的檔案目錄結構來說要完成是有難度的，實現是可以的，就像查詢檔案那樣。不過那樣的話，大家都知道，是很花時間的，基本上不能滿足使用者的需要。於是我們就需要重新設計乙個既合乎需要又能繼承以往檔案系統優點的新的的檔案系統結構。
2.基於檔案id的目錄區(檔案分配表區)
要做到對使用者的檔案與路徑的透明性，就必須在目錄區表達出來。基於檔案id的目錄區的基本思想是對檔名等重要資訊進行hash運算。做個最簡單的例子來說，在目錄區里我們儲存的僅僅是檔名的hash值(即檔案id)和檔案起始簇資訊兩個域。通過乙個盡量避免衝突的hash運算來生成檔名對應的id,至於其它的資訊我們都可以儲存在檔案的內容裡邊.檔案內容也做個改變，在內容的頭上加上檔案的控制資訊(如檔名,目錄的id,日期,大小等)和自定義的資訊(可以像xml一樣,使用者自由擴充套件)，在使用者介面上顯示檔案時這些時不顯示出來的，而是作為控制資訊顯示在資源管理器中的。現在我們再來考慮前面提到的獲取file1.txt的問題,分幾步完成:一.檔案系統管理程式通過hash運算,把file1.txt轉換成乙個數字n;二.在檔案分配表裡查詢這個數字,由於我們每個目錄記錄只有倆個域的值,所以這個目錄區很小,查詢很快;由於hash結果不可能避免衝突,所以查詢的結果可能不唯一.三.讀出查詢結果檔案的內容,得到檔案的真實名稱,得到file1.txt;如果有多於乙個結果,那就是其他的目錄中存在同名檔案,詢問使用者確切的需要;四.提交給使用者,完成操作.
從以上可以看出,基於檔案id的目錄區技術很好解決的檔案系統目錄層次複雜的問題,很大程度上方便了使用者的操作,提高了使用者的工作效率.同時也帶來了額外的好處:
一.提高了查詢速度.有兩個原因,一是檔案目錄區大大減小,減小了讀磁碟的負擔;二是不用進行費時的檔名字串的匹配,而是進行簡單的數字比較.
二:通過把檔案的控制資訊放在檔案內容裡邊,並用xml格式進行存貯,系統和使用者可以有完全的靈活性修改檔案的控制資訊,對檔案進行個性化的描述.
三.檔名長度,檔案大小等再也不受限制.因為我們是把檔案的控制資訊放在檔案內容裡,所以檔名可以任意長,也不會浪費磁碟空間.檔案大小也可以不受限制.
四.適合檢索.檔案控制資訊以xml格式存貯,應用程式或使用者或就可以在裡面加入檔案的關鍵字等資訊,跟xml的對搜尋的考慮是有相同好處的.
這些只是乙個大概的輪廓,在具體實現是可能會有一些另外的問題,那就留給其他人討論了.
2002-8-26
一種共享位置服務的設想
共享位置服務是指有一定合作關係的團隊，內部每個成員向其它成員提供自己的地理位置資訊，以達到合作配合的作用。乙個最簡單的例子，我們在玩一些網路遊戲 例如魔獸 之類的時候，一般會有個小地圖來顯示隊友或敵方所在的位置，這些共享的位置資訊可以幫助我們為接下來的戰略做好計畫和準備。而在真實生活中，同樣也有很多...
一種Handle結構
最近看到了這樣一篇部落格，感覺寫的很好。尤其是它其中敘述的這種基於事件的模型。我也是照貓畫虎的寫了個示例程式，不知道對不對我斗膽描述一下這個結構 1.定義乙個介面，定義需要提供的服務。2.定義乙個抽象類 或者普通的類 實現上述介面，實現介面的所有服務，實現內容都為空的。3.接下來，使用者可以根據自己...
一種基於微博的餵狗裝置實現設想
因為看到國外程式設計師用推特餵狗，以至於大家都去給他傳送 餵狗的命令，以至於他不得不調整程式以控制餵食時間段，以免狗變加菲狗。於是就想到這種方式是怎麼實現的呢？我的設想如下 動力裝置 實現這套東西，初始感覺得懂嵌入式的東西，這樣才好控制機器啥的，不過又想了一下，普通的機箱或者筆記本上，也有類似動力裝...