rsync写入挂载但不可达的NFS共享时，删除源文件选项的行为咨询

Great question—this is a super common edge case with network filesystems like NFS, so let's break it down clearly:

Core Behavior of --remove-source-files #

First, it's critical to remember how rsync's --remove-source-files works: it only deletes a source file after that file has been successfully copied to the destination. Rsync doesn't delete anything upfront; it waits for explicit confirmation that the write to the target completed without errors.

Scenario with Unreachable (But Mounted) NFS #

When your NFS share shows as "mounted" but is actually unreachable, any attempt to write to it will throw an I/O error (you’ll likely see messages like Input/output error in rsync’s output). Here’s exactly what plays out:

• Rsync will attempt to transfer each file, but the write operation to the NFS share will fail immediately.
• Since the transfer didn’t succeed, rsync will not delete the corresponding source file—it sticks strictly to its "success-first" rule.
• The entire rsync operation will exit with a non-zero status code (signaling failure), and you’ll get clear error logs explaining the I/O issues blocking the transfer.

Rare Edge Case to Keep in Mind #

In extremely unusual scenarios where the NFS server incorrectly returns a "write success" signal even though the share is unreachable (this is almost never seen with properly configured NFS), rsync might mistakenly delete the source file. But this is a total edge case—standard NFS behavior will return unambiguous I/O errors when the share is down, so rsync will abort the transfer for that file and leave your source data intact.

Quick Safe Test Tip #

If you want to verify this without risking real files, simulate an unreachable mount (e.g., unmount the NFS share but leave the empty mount point, or use a loopback filesystem you intentionally break) and run a test rsync with --dry-run --remove-source-files—this shows you the intended behavior without actually deleting anything.

内容的提问来源于stack exchange，提问作者J Telep