Bug 14183 - rsync fails transferring only attributes for file without write permission
Summary: rsync fails transferring only attributes for file without write permission
Status: NEW
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.3
Hardware: x64 Mac OS X
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-05 22:20 UTC by Eric Postpischil
Modified: 2019-11-05 22:20 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 Eric Postpischil 2019-11-05 22:20:18 UTC
When a file’s extended attributes have changed but its contents have not and the user does not have write permission for the source file (irrespective of the destination file permissions), rsync fails with a permission error from lsetxattr.

Using rsync 3.1.3 on macOS 10.14.6, the output of these commands:

	cd /var/tmp
	mkdir stage
	mkdir stage/{source,destination}
	touch stage/source/foo
	rsync -a --xattrs stage/source/ stage/destination/
	xattr -w abc def stage/source/foo
	chmod ugo-w stage/source/foo
	rsync -a --xattrs stage/source/ stage/destination/

is:

	rsync: rsync_xal_set: lsetxattr("/private/var/tmp/stage/destination/foo","abc") failed: Permission denied (13)
	rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1189) [sender=3.1.3]

Note that if "echo ghi >stage/source/foo" is inserted after the first rsync, the second rsync is perfectly happy to update the file, including the extended attributes. Only when the extended attributes but not the contents are being updated does rsync encounter the permissions problem.

These commands demonstrate the problem with both sides local, but it occurs with a remote side as well.

This problem is not evident in the rsync 2.6.9 distributed by Apple with macOS.