關於檔案的儲存 windows和Linux比較

2021-09-03 10:21:06 字數 1651 閱讀 9029

大家都知道在數字計算機領域內指的檔案在磁碟上的儲存是依賴於檔案的命名的。

昨天我偶然的機會處理了乙個在rhel6.1作業系統上的ext4分割槽中的資料夾,這個資料夾盛放的是乙個標準使用者的home目錄(家目錄)。在執行備份過程中,我錯誤的將其備份(複製)到乙個ntfs分割槽的磁碟中,然後用windows server 2008 r2作業系統開啟了這個分割槽。但是我馬上認識到了錯誤,既然已經造成了這個錯誤就趁機看看windows是如何處理這個目錄的。

下面是此目錄(此目錄假設以home命名)在ext4檔案系統中的部門檔案結構。

/home

根目錄中有兩個資料夾

/home/workspace

/home/workspace

兩個資料夾中的檔案不相同

分別為/home/workspace/documentcatalog/computing

/home/workspace/documentcatalog/cloudcomputing

和/home/workspace/cprograming_desigan/chroot.c

/home/workspace/cprograming_desigan/a.out

結果當將這個磁碟連線到windows系統時,首先系統沒有報錯,可以正常訪問磁碟。

接下來我有意識的開啟根目錄,發現了這個目錄中的確有兩個資料夾/home/workspace和/home/workspace,但是當我要訪問這兩個資料夾時,奇妙的現象就出現了。

結果令我感到很震驚,兩個目錄中的檔案完全相同。所謂的完全就是時間、許可權和屬性都是完全一樣的。

那麼沒有出現的那些檔案**去了呢?我還能夠正常訪問它們嗎?

結果肯定是不能。

然後我嘗試了複製這個目錄(home),發現複製成功,但是不能貼上,貼上是有效的,但是實際上執行貼上命令後沒有任何反應。

怎麼辦?

首先我考慮到了windows平台中的使用工具chkdsk,

我在cmd中執行了chkdsk /f g:(假設磁碟分割槽分配的符號為g:)。

果然在意料之中出現了各種掃瞄到的錯誤,都是關於檔案索引的錯誤(可惜我當時忘記了截圖)。

當修復完成後,發現可以正常的使用該磁碟分割槽了。

但是後來遇到的結果依然令我驚訝!原來,chkdsk這一工具將有以上錯誤的目錄和檔案全部都「清除了」!我發現不任何原先有類似錯誤的檔案的位置。

這肯定是我不希望看到的。

當時我很驚恐,因為所備份的磁碟的備份在另一台遠端計算機的磁碟上,且處於保護(沒有實現共享,即其他主機不可見)狀態,而裡面又有我當天需要使用的檔案。

怎麼辦?

我想切換到rhel環境中再試一試,但想了想這個方案不可行,因為windows已經修復並儲存了磁碟的檔案系統。

嘗試檔案恢復?使用檔案恢復工具?這個在windows server平台上又沒有支援較好的軟體,這也是一大缺憾。應該是相容性吧!測試了幾次,效果依然不太好。

此刻我又想到了,每次執行chkdsk這一工具後都會在其分割槽中產生found.000資料夾,我檢視了一下此資料夾中的檔案和目錄,正好有我要尋找的目錄和檔案。只是存在錯誤的目錄或檔名稱全都變了。總之還好,在rhel上能正常識別出來。

這次的事故讓我體會到了平時關於在檔案的命名和備份分割槽的選擇上的注意事項。當當前計算環境中有多個不同的作業系統或者分割槽型別時就應該本著通吃通用的原則,以保證檔案的可用性。

關於mongodb的檔案儲存的使用

gridfs是用於儲存和檢索超過bson文件大小限制16 mb的檔案的規範。gridfs不將檔案儲存在單個文件中,而是將檔案分為多個部分或塊 1 並將每個塊儲存為單獨的文件。預設情況下,gridfs使用預設塊大小255 kb 也就是說,gridfs將檔案劃分為255 kb的塊,最後乙個塊除外。最後乙...

關於讀寫儲存本地檔案

關於讀寫儲存本地檔案 將資料寫入到檔案 return 是否寫入成功 bool writetofile nsstring doc nssearchpathfordirectoriesindomains nsdocumentdirectory,nsuserdomainmask,yes lastobjec...

Linux和Windows共享儲存的配置方式

在linux下訪問windows共享目錄的配置方法 1 在windows上設定乙個共享目錄 如 將d redhat disk設定為共享目錄 2 在windows上建立乙個使用者,如tommy,密碼111111 3 將tommy使用者加入到共享目錄d redhat disk的訪問組中,並設定tommy...