rsync 不報告要刪除的文件

我看過這個（和這裡的論壇文章）和這個。

我試過在 Python 和命令行中執行。我已經仔細檢查過：某些文件肯定已從源中刪除，但存在於link-dest目標中。我已經嘗試過多種選擇。我嘗試在路徑末尾添加正斜杠，看看是否會有所作為。所有情況下的路徑都是簡單的目錄，永遠不會以全域模式結束。我還查看了手冊頁。

順便說一句，這無關緊要，但你永遠不知道：我在 WSL（W10 OS）下執行它。

似乎沒有任何效果。

順便說一句，在源中刪除的文件確實會在目標位置（如果不是試執行）中被刪除（或者更確切地說沒有被複製）。

我要做的是找出link-dest位置和源之間發生了哪些變化，以期在沒有任何變化的情況下取消操作。但要做到這一點，我必須能夠獲得新文件或修改文件以及已刪除文件的列表。

這是我一直在嘗試的 Python 程式碼：

link_dest_setting = '' if most_recent_snapshot_of_any_type == None \
   else f'--link-dest={most_recent_snapshot_of_any_type[0]}'
rsync_command_args = [ 'rsync', 
                      '-v', 
                      # '--progress',
                      # '--update', 
                      '--recursive', 
                      '--times', 
                      '--delete', 
                      # '--info=DEL', 
                      '-n', 
   link_dest_setting, source_dir, new_snapshot_path, ]
print( f'running this: {rsync_command_args}')    
result = subprocess.run( rsync_command_args, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
rsync_result_stdout = result.stdout.decode( 'utf-8' )
print( f'rsync_result stdout |{rsync_result_stdout}|')
rsync_result_stderr = result.stderr.decode( 'utf-8' )
print( f'rsync_result stderr |{rsync_result_stderr}|')

典型stdout（帶試執行）：

rsync_result stdout |sending incremental file list
./
MyModifiedFile.odt

sent 1,872 bytes  received 25 bytes  3,794.00 bytes/sec
total size is 6,311,822  speedup is 3,327.27 (DRY RUN)

|

（中沒有錯誤報告stderr）

剛剛找到另一種選擇，-i. 使用這個東西變得非常神秘：

rsync_result stdout |sending incremental file list
.d..t...... ./
>f.st...... MyModifiedFile.odt

sent 53,311 bytes  received 133 bytes  35,629.33 bytes/sec
total size is 6,311,822  speedup is 118.10
|

編輯

典型的 BASH 命令：

rsync -virtn --delete --link-dest=/mnt/f/link_dest_dir /mnt/d/source_dir /mnt/f/destination_dir

試執行，原則上應該顯示文件/目錄存在於 link_dest_dir 下但不存在（刪除）在 source_dir 下。我不能讓這個顯示出來。無論如何，我認為 Python 答案可能是一個更可取的解決方案，因為掃描在第一次檢測到差異時停止。

編輯 2

（回答 roaima 的問題“你在保存什麼？”）

我的“我的文件”目錄有大約 6 GB 和數千個文件。如果沒有發現差異（如果有差異，則更短），我的 Python 腳本需要 15 秒左右才能掃描它。rsync通常需要大約 2 分鐘來完成複制（對絕大多數文件使用硬連結）。如果發現這是不必要的，因為源和位置之間沒有變化，link-dest那麼我將不得不刪除所有這些文件和硬連結。就時間而言，刪除操作本身是非常昂貴的。順便說一下，這是一個外置高畫質旋轉板類型。不是有史以來最慢的儲存位置，但它有它的局限性。

同樣重要的是，因為rsync至少根據我的發現似乎無法報告源中已刪除的文件，我怎麼會知道這個新快照與快照相同link-dest？在這些快照位置，我只想保留有限數量（例如 5 個）的快照，但我只想在新快照與其前身不同時添加新快照。因此，儘管腳本可能每 10 分鐘執行一次，但相鄰快照之間的間隔可能是 40 分鐘，或者更長。

我看到你（roaima）的聲望很高，而且似乎在rsync. 我想回答的一個簡單問題是：是否可以rsync在試執行時報告源中相對於link-dest? 如果不是，這是一個錯誤/缺陷嗎？因為手冊頁確實似乎聲稱（例如--info=DEL）這應該發生。

你問題的關鍵部分似乎是這些，

我只想添加與其前身不同的新快照。因此，雖然腳本可能每 10 分鐘執行一次，但相鄰快照之間的間隔可能是 40 分鐘，或者更長

和

rsync 是否可以在試執行時報告相對於連結目標在源中刪除的文件或目錄

我在這裡的理解是您已經實現了一個版本rsnapshot，每次您考慮備份時，以前的備份目錄都會成為您的--link-dest目錄。最大的區別在於，如果目前源樹和最近的備份之間沒有變化，那麼在你的情況下，不需要進行備份。

在我的簡短實驗中，似乎可以簡單地查看以下輸出rsync：如果有輸出，​​則有工作要做，如果沒有，則沒有。關鍵是直接查看連結目錄

output=$(rsync -rti --delete --dry-run "$src/" "$lnk/" 2>&1 | grep -v '^[^*]d' | head -n1)
if [ -n "$output" ]
then
   # Work to be done
   rsync -rtiv --link-dest "$lnk/" "$src/" "$dst"
fi

目前我已經從測試中省略了目錄，因此對目錄的更改不會觸發備份。如果您也關心對目錄的更改，請grep從測試中刪除過濾器

引用自：https://unix.stackexchange.com/questions/636346