Bug 10893 - Allow option to sync symlinks last (or delayed)
Allow option to sync symlinks last (or delayed)
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
3.1.1
All All
: P5 enhancement
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-23 17:40 UTC by moffatjd
Modified: 2014-10-23 17:40 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description moffatjd 2014-10-23 17:40:14 UTC
Presently rsync will create symlinks first (on the receiver side) and then it will sync the content that is potentially being linked. This can cause race conditions on the receiver side.

For example, given the small hierarchy already existing on the receiver side:

/foo -> foo_1.0
/foo_1.0

And then assume we have an updated hierarchy on the sender side:

/foo -> foo_2.0
/foo_1.0
/foo_2.0

When rsync updates the receiver side with the new foo_2.0, it first does the symlink (pointing foo to foo_2.0) but the contents of foo_2.0 have not been synced yet. During this time frame (when link is sycned, but content is not) the symlink points to a non-existent directory. If a program on the receiver side should reference foo during the rsync, it will fail.

The option --delay-updates does not fix this behavior, and is the closest option available to obtaining this 'atomic' like behavior.

Please consider an option --link-after (similar to --delete-after) that simply waits and does all symlinks after all updates.

OR

Please consider creating a --delay-links option that would not sync a link until the content of the link (including subdirs) is complete. 


Thank you.