Log data sent/received even if error#5
Merged
Conversation
tridge
added a commit
to tridge/rsync
that referenced
this pull request
May 20, 2026
…(defer dir immutable, batch flag) RsyncProject#5 (medium): batch.c didn't record preserve_fileflags, so --write-batch --fileflags emits an extra word per file in the file-list stream (XMIT_SAME_FLAGS bit + fileflags word) that --read-batch wouldn't expect without the matching option. Added preserve_fileflags at slot 15 of flag_ptr/flag_name, marked "protocol 30+, requires varint flags" so the bit-position remains stable. Older rsync readers ignore unknown high bits, so this is backwards-readable; newer readers of an old batch see bit 15 unset and correctly leave preserve_fileflags at 0. RsyncProject#4 (medium): if a source directory has immutable / append bits in SAFE_FILEFLAGS (e.g. chflags uchg dir/), set_file_attrs in recv_generator applied them to the dest dir BEFORE the children inside the dir were populated -- and the +i then blocked rsync from creating those children at all. Pass ATTRS_DELAY_IMMUTABLE in the recv_generator set_file_attrs call for dirs, mirroring how finish_transfer already defers immutable bits for temp-then- rename files. touch_up_dirs now re-applies the deferred bits after all children have been processed. RsyncProject#2 (high): the early `continue` in touch_up_dirs at "no times to retouch and no perms to fix" skipped the per-directory force_change restore (undo_make_mutable) too -- so --force-change --omit-dir-times on a +i source dir was leaving the dest dir permanently mutable. Same issue would now affect the new --fileflags deferred-apply path without the fix. Split the continue condition: never skip if there's a force_change restore pending OR a deferred --fileflags apply pending OR the existing times/perms work. Side effect of the RsyncProject#4 fix: set_fileflags() is no longer static because the new touch_up_dirs path calls it directly (cleaner than overloading undo_make_mutable's name). Testsuite addition: fileflags.test now exercises the deferred- immutable-on-dir scenario when the test user can set uchg (only on BSD/macOS or as root on Linux). Creates a uchg source dir with children, rsyncs, asserts the children are present AND the dest dir ends up with uchg set -- which means rsync deferred the bit until after the children populated. Verified Linux/ext4 full suite 60 passed / 2 skipped / 0 failed (the new test block self-skips on non-root Linux since chattr +i needs CAP_LINUX_IMMUTABLE). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tridge
added a commit
to tridge/rsync
that referenced
this pull request
May 20, 2026
…ncProject#6 (chmod mode arg) These two small syscall.c fixes were made at the start of the round-4 work but got dropped on the floor when I split the commit -- only the docs (RsyncProject#1) and the bigger RsyncProject#2/RsyncProject#4/RsyncProject#5 deferred-immutable-dir series ended up landed. The tree was left dirty. RsyncProject#3: do_rename (the non-_at variant) was missing the hardlink-aware restore I added to do_rename_at last round. Same shape -- when renameat replaces a destination inode that had st_nlink > 1, the remaining hardlinks survive carrying the cleared flags. Restore via new_fd before close (the fd still refers to the surviving inode). RsyncProject#6: do_chmod and do_chmod_at force_change recovery were calling make_mutable_fd(fd, mode, ...) where mode was the caller-supplied chmod-target mode -- some callers (notably xattrs.c's set_xattr recovery path) pass perm bits only, no S_IFREG / S_IFDIR, so on Linux rsync_fchflags rejects the call as neither regular file nor directory and recovery silently fails. Use st.st_mode from the freshly-fstatted target instead, which always has the right S_IFx bits. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Hi,
This PR allows the daemon to log data sent/received even in case of error, which can be interesting to have when the transfer has been interrupted by the client.
Many thanks 👍
Initial report there, pushed here by convenience.