解決由於經常將一些以前的檔案刪除，而現今或者以後可能用到的尷尬境地。
ai雲盤系統功能具體可分為兩大塊：分別是客戶端和服務端兩大部分。客戶端與服務端通訊的協議是基於http協議。客戶端：1.首先獲取檔案的備份資訊記錄，目的是看看哪些檔案已經進行了備份，並將這些檔案的大小和修改資訊以鍵值對的形式儲存到unordered_map中。2.接下來對指定的目錄進行監聽，如果是目錄則進行遞迴監聽直到檔案被掃瞄完畢。判斷這些檔案是否需要上傳，通過獲取它們的etag資訊裡面有檔案大小和最後一次修改時間。並且將這些資訊與unordered_map中儲存的修改資訊進行對比，如果發生改變則需要上傳否則不需上傳。
3.當需要上傳時，則對檔案採取分塊上傳的方式（提高效率）。將每個塊進行記錄原位置，並進行組織http請求，設定它的請求方式，上傳路徑，上傳資料長度。之後呼叫httplib.h中的上傳介面例項化客戶端物件來向指定的服務端傳送put請求，利用多執行緒將這些分塊進行上傳。
4.在上傳完畢後，將這些檔案的etag資訊儲存到unordered_map中。
5.最後將unordered_map中儲存的備份檔案資訊記錄重新整理到備份檔案資訊的檔案中。
在客戶端所遇到的問題：
1.在分塊上傳檔案時，起初考慮到如果最後一塊不夠乙個塊大小就將它和最後一塊進行上傳。所以塊大小少了乙個。這樣看似沒有問題，但是當檔案不夠乙個塊大小時，就會出現問題。導致上傳失敗。
解決辦法：我將開始分塊時首先判斷是不是可以切分為整塊，如果是則正常上傳，如果存在不夠乙個塊的情況，將塊個數+1，並重新計算最後乙個塊的末尾位置。這樣就可以按照統一方式進行上傳。只是根據具體檔案大小判斷需不需要多建立乙個分塊來上傳就可以了。
2.boost庫中函式split分割函式的問題，由於將第三個引數設定為以\n分割。導致的總報錯說如圖：
解決辦法：後查資料沒有發現問題，求助老師後，說split分割的第三個引數是以boost::is_any_of("\n")。得以實現
服務端：
1.提供解析對客戶端發來的put請求資訊。並將傳來的資料進行備份。
2.服務端對客戶端提供獲取備份檔案列表的功能。
4.服務端每隔一定時間對檔案進行判斷是否需要進行壓縮處理一次，目的使得磁碟空間充分利用。
1.服務端在對客戶端傳送過來的請求資訊進行解析，拿到上傳檔案路徑及range的資訊，裡面有塊大小，起始位置，結束位置。服務端將資料備份到對應位置檔案的對應位置上。
2.當客戶端通過瀏覽器瀏覽備份的檔案時。此時伺服器通過儲存的備份檔案資訊的列表來獲取相應檔名。
4.每次當服務端起來，就建立乙個執行緒，首先獲取，備份壓縮檔案資訊。儲存到unordered_map中。接著對list目錄下檔案進行檢測。判斷檔案檔案是否可以壓縮。通過該檔案的當前時間和stat結構體中儲存的檔案訪問時間之差來進行判斷，在這裡我設定了兩天。為了測試方便設定了10秒。如果大於非壓縮時間，就將檔案進行壓縮，呼叫zlib.**件壓縮的函式gzwrite。讀取原始檔，並用gzwrite進行壓縮寫入。並將壓縮的檔案資訊儲存到unordered_map中。
5.最後將unordered_map中的壓縮檔案資訊儲存到record.list中。用來記錄壓縮檔案的壓縮檔案名，以及壓縮檔案名。
在服務端所遇到問題：
2.增加伺服器分塊上傳檔案功能，遇到問題：ofstream寫入預設截斷寫入導致前面亂碼，改用系統呼叫介面
珍&原始碼
初夏小談 類和物件（一）
所以在c 中把處理問題的步驟進行包裝就形成了類。這個類可以處理特定的問題，而不用去關注它是怎麼一步步處理的。在c 中類用class來標識，struct也可以。類中不僅可以定義變數，還可以定義函式。例如 struct student void printstu 成員變數 char name 20 ch...
初夏小談 複雜鍊錶的複製
在鍊錶的中有這樣一類鍊錶。它至少包含兩個指標。其中乙個指向下乙個結點。有乙個指標隨機的指向鍊錶的其它結點，也可能指向它自己，也可能指向null。對於該類鍊錶的複製來說。最大的難度就是如何處理複製的新鍊錶的這個隨機指標指向的問題。因此在對該類煉表處理時，就必須根據源鍊錶的指標指向來得到新鍊錶的隨機指標...
初夏小談 叩響C 世界的大門
今天開起c 大門，c 對c語言的許多缺陷進行了改進，但是總是會存在一些未知的問題，等著我們共同努力去發現解決。c 是乙個不斷發展改進的過程，它的魅力也是居高不下。在排行榜中基本緊跟老大哥c語言的步伐。哈哈 今天來說說c 一些基礎共有十一大部分 之所以要引進命名空間就是因為當乙個專案有很多原始檔一起執...