Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

75%
+4 −0
Q&A Can rsync handle moves and renames?

I'm quite certain that rsync is not able to deduce that /path/to/src/folder_a/file_w on one side of the transfer is identical to /path/to/src/folder_c/file_w on the other side of the transfer. The...

posted 3mo ago by Canina‭

Answer
#1: Initial revision by user avatar Canina‭ · 2024-01-25T17:48:55Z (3 months ago)
I'm quite certain that rsync is not able to deduce that /path/to/src/folder_a/file_w on one side of the transfer is identical to /path/to/src/folder_c/file_w on the other side of the transfer.

**Therefore, rsync won't be able to handle such a move efficiently.** To stock rsync, it will appear as one file having been deleted and the other having been created.

There are basically two ways of handling this:

 * Independently make the same changes on both sides of the transfer. That's easy for a single file, or if you control both sides and can access them simultaneously; but that might not always be practical.
 * Use a tool better suited for such change detection.

For example, if the (in this case) source code is in a Git repository, you can use [`git mv`](https://git-scm.com/docs/git-mv) to rename the parent directory; this should allow the tooling to keep track of which file is which even after the rename. Other version control systems will likely have ways to do much the same thing.

Alternatively, you can use a tool such as [unison](https://github.com/bcpierce00/unison/blob/master/README.md), possibly in one-way mode, to synchronize changes. I can attest to that it generally successfully detects and handles renames without re-transferring the file, but it relies on a fairly hefty chunk of external metadata to do so efficiently, and generally wants to either do the initial transfer itself or start with two identical trees; using it to transfer such a change after it has already been made would probably be risky.