Repository navigation
receiver: add --delay-symlinks - #1124
Merged
Merged
Conversation
The generator creates a symlink as soon as it reaches it in the file list, while regular files arrive later through the sender and receiver (and, with --delay-updates, are only renamed into place at the end). For the rest of the transfer a new symlink can point at a file that isn't there yet, so anything reading the destination during the sync -- e.g. a loader resolving libfoo.so -> libfoo.so.2 -- can fail. The new --delay-symlinks option makes the generator defer new and changed symlinks and create them once the receiver reports that every file, including any --delay-updates renames, is in place. Each link is itemized and logged after it has been created, before the generator ends the delay-updates phase, and the deletion stats are sent after any directory that a deferred link replaces. The option implies --no-inc-recursive on the receiving side and is passed to a remote receiver, which must also support it. It is an error to combine it with --remove-source-files, --hard-links, --compare-dest, --copy-dest, or --link-dest, or to use it with a protocol older than 29. support/rrsync accepts the option and refuses it under -no-overwrite, as it does --delay-updates. Add delay-symlinks_test.py, which holds a push partway through the link's target to check that new and changed links aren't created early, and rrsync-no-overwrite-delay-symlinks_test.py.
steadytao
requested changes
Oct 10, 2026
The man page now says the option narrows the inconsistency window rather than making the update atomic, that an interrupted transfer leaves new symlinks missing and changed ones at their old targets, and that --delete-before can also remove an old target early. Add delay-symlinks-remote_test.py. Through a remote shell that records the server command, it checks that the option is passed to a remote receiver on a push but not to a remote sender on a pull, and that incremental recursion is off in both directions. It also checks that --protocol=28 fails with the protocol error, and that a push to an older rsync (old_versions/rsync_3.4.1) is refused before anything is transferred while a pull from it works.
steadytao
changed the title
steadytao
force-pushed
the
delay-symlinks
branch
from
October 11, 2026 03:37
2419066 to
f984b86
Compare
steadytao
force-pushed
the
delay-symlinks
branch
from
October 11, 2026 03:41
f984b86 to
5c97710
Compare
steadytao
approved these changes
Oct 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The generator creates a symlink as soon as it reaches it in the file
list, while regular files arrive later through the sender and receiver
(and, with --delay-updates, are only renamed into place at the end).
For the rest of the transfer a new symlink can point at a file that
isn't there yet, so anything reading the destination during the sync --
e.g. a loader resolving libfoo.so -> libfoo.so.2 -- can fail.
The new --delay-symlinks option makes the generator defer new and
changed symlinks and create them once the receiver reports that every
file, including any --delay-updates renames, is in place. Each link is
itemized and logged after it has been created, before the generator
ends the delay-updates phase, and the deletion stats are sent after any
directory that a deferred link replaces.
The option implies --no-inc-recursive on the receiving side and is
passed to a remote receiver, which must also support it. It is an
error to combine it with --remove-source-files, --hard-links,
--compare-dest, --copy-dest, or --link-dest, or to use it with a
protocol older than 29. support/rrsync accepts the option and refuses
it under -no-overwrite, as it does --delay-updates.
Add delay-symlinks_test.py, which holds a push partway through the
link's target to check that new and changed links aren't created early,
and rrsync-no-overwrite-delay-symlinks_test.py.
Resolves #1118.