Skip to content

Symlinks can be dangling during the sync #1118

Description

@rajputa-deshaw

Since rsync creates symlinks on the receiving side as it is walking through the file list, a symlink can be dangling until the file that it points to has been copied. With --delay-updates, this duration becomes even larger.

Could we hold back the symlink creation until all regular files are in place? Even an opt-in flag for this behavior would be helpful. I have a sample LLM generated implementation here. I can refine it and create a PR if this can be added.

Activity

  1. steadytao commented on Oct 8, 2026

    @steadytao
    Member

    This would be a consistency-window feature, not an atomic update. Open to discussing implementations.

  2. rajputa-deshaw commented on Oct 8, 2026

    @rajputa-deshaw
    ContributorAuthor

    This would be a consistency-window feature, not an atomic update.

    I agree with this.

    Proposed implementation (diff): a new opt-in --delay-symlinks option.

    • On the receiving side, the generator holds back new and changed symlinks instead of creating them as soon as it reaches them in the file list. Each one is still itemized and logged at its normal place; only creating it moves.
    • Once the receiver signals it has finished (the same NDX_DONE the generator already waits for after the --delay-updates renames), the generator creates the held-back links with atomic_create(), after re-checking each destination. This happens before --delete-delay/--delete-after deletions and before touch_up_dirs().
    • --delay-symlinks works both with or without --delay-updates. It is forwarded to a remote receiver and implies --no-inc-recursive on the receiver.
    • Symlinks are not held back with --remove-source-files or --dry-run, or when they're hard-linked together under -H.
  3. steadytao commented on Oct 9, 2026

    @steadytao
    Member

    That branch silently disables the option for hard-linked symlinks and --remove-source-files. An old receiver rejects --delay-symlinks before the claimed protocol fallback can occur. It also itemises links before deferred creation can fail. Make incompatible combinations explicit errors, keep itemisation truthful and replace the ctime assertion with deterministic synchronisation before opening a PR please.

  4. rajputa-deshaw commented on Oct 10, 2026

    @rajputa-deshaw
    ContributorAuthor

    I have created #1124 with the suggested changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions