可以恢復失敗文件傳輸的程序如何知道從哪裡開始附加數據？
一些文件複製程序喜歡
rsync並且curl能夠恢復失敗的傳輸/複製。請注意，這些故障可能有很多原因，在某些情況下程序可以“清理”某些情況下程序不能。
當這些程序恢復時，它們似乎只是計算成功傳輸的文件/數據的大小，然後開始從源讀取下一個字節並附加到文件片段上。
例如，“成功”到目標的文件片段的大小是 1378 字節，因此它們只是從原始字節 1379 開始讀取並添加到片段中。
我的問題是，知道字節是由位組成的，並且並非所有文件都將其數據分段為乾淨的字節大小的塊，這些程序如何知道他們選擇開始添加數據的點是正確的？
當寫入目標文件時，會在程序、核心或文件系統級別發生類似於 SQL 數據庫的某種緩衝或“事務”，以確保只有乾淨、格式良好的字節才能到達底層塊設備？
或者程序是否假設最新的字節可能不完整，所以他們假設它壞了就刪除它，重新復製字節並從那裡開始追加？
知道並非所有數據都表示為字節，這些猜測似乎不正確。
當這些程序“恢復”時，他們如何知道他們從正確的地方開始？
為了清楚起見——真正的機制更複雜，以提供更好的安全性——你可以想像這樣的寫入磁碟操作：
應用程序寫入字節(1)
核心（和/或文件系統 IOSS）緩衝它們
一旦緩衝區滿了，它就會被刷新到文件系統：
- 該塊已分配 (2)
- 塊被寫入 (3)
- 更新文件和塊資訊 (4)
如果程序在 (1) 處中斷，則磁碟上沒有任何內容，文件完好無損，並在前一個塊處被截斷。您發送了 5000 個字節，磁碟上只有 4096 個字節，您在偏移量 4096 處重新開始傳輸。
如果在 (2) 處，除了在記憶體中什麼都不會發生。同（1）。如果在 (3) 處，數據已寫入，但沒有人記得它。您發送了 9000 個字節，寫入了 4096 個字節，寫入了 4096 個字節並失去了，其餘的只是失去了。轉移在偏移量 4096 處恢復。
如果在 (4) 處，則數據現在應該已送出到磁碟上。流中的下一個字節可能會失去。您發送了 9000 個字節，寫入了 8192 個字節，其餘的失去了，傳輸在偏移量 8192 處恢復。
這是一個簡化的鏡頭。例如，階段 3-4 中的每個“邏輯”寫入都不是“原子的”，而是產生另一個序列（讓我們將其編號為 #5），從而將塊細分為適合目標設備（例如硬碟）的子塊) 被發送到設備的主機控制器，主機控制器也有記憶體機制，最後儲存在磁碟上。這個子序列並不總是完全在系統的控制之下，因此將數據發送到硬碟並不能保證它已經被實際寫入並且可以讀取回來。
幾個文件系統實現了日誌，以確保最易受攻擊的點 (4)實際上不是易受攻擊的，通過將元數據寫入，您猜對了，無論在階段 (5) 發生什麼，事務都將始終如一地工作。
如果系統在交易過程中被重置，它可以恢復到最近的完整檢查點。寫入的數據仍然失去，與案例 (1) 相同，但恢復會處理這一點。實際上沒有資訊失去。