On FreeBSD at least, -a --flags does not perform the intended function: # touch f1 # chflags schg f1 # mkdir dest # rsync -axvH --flags f1 dest building file list ... done f1 rsync: rename "/tmp/dest/.f1.Isi7Bm" -> "f1": Operation not permitted (1) sent 91 bytes received 42 bytes 266.00 bytes/sec total size is 0 speedup is 0.00 rsync error: some files could not be transferred (code 23) at main.c(892) [sender=2.6.8] # ls -latro dest total 4 -rw-r--r-- 1 root wheel schg 0 Aug 2 15:36 .f1.Isi7Bm drwxrwxrwt 8 root wheel - 512 Aug 2 15:36 .. drwxr-xr-x 2 root wheel - 512 Aug 2 15:36 . #
Same problem; -a not needed; just trying to rsync a file with certain flags fails the same way. Looks like rsync sets the flags on the transferred temporary copy but FreeBSD flags like schg or nouunlnk prevent the temporary copy from being renamed. Can the flags be set after the rename?
The latest CVS has a revised version of the flags.diff patch that I believe should take care of this. The patch compiles on NetBSD, but I have no way to test it (since chflags isn't cooperating). http://rsync.samba.org/ftp/unpacked/rsync/patches/flags.diff Apply that to 2.6.9pre2 and let me know if there is still an error.
I did apply this patch to 2.6.8 with a minor patch modification. But it doesn't work: # touch f1 # chflags schg f1 # mkdir dest # rsync -axvH --flags f1 dest rsync: file flags are not supported on this client rsync error: syntax or usage error (code 1) at main.c(1231) [client=2.6.8] # I don't see any indication that the patch will apply to 2.6.9pre2 only. Or is there?
(In reply to comment #3) > rsync: file flags are not supported on this client > rsync error: syntax or usage error (code 1) at main.c(1231) [client=2.6.8] Be sure to run autoconf and ./configure after applying the patch.
OK. This new patch doesn't actually *replace* patches/flags.diff... but autoconf & autoheader solved it. However the original problem remains: # touch f1 # chflags schg f1 # mkdir dest # rsync -axvH --flags f1 dest building file list ... done f1 rsync: failed to set file flags on "/tmp/q/dest/f1": No such file or directory (2) rsync: rename "/tmp/q/dest/.f1.JITFX8" -> "f1": Operation not permitted (1) sent 91 bytes received 42 bytes 88.67 bytes/sec total size is 0 speedup is 0.00 rsync error: some files could not be transferred (code 23) at main.c(977) [sender=2.6.9pre2] #
The call to make_mutable() was using fname when it should have used fnametmp. The latest patch in CVS fixes this. The code does not try to allow an immutable file in the destination to be updated, and I assume that's how things should work.
Yep. This indeed fixes the original bug. Thanks! However, I disagree on handling an immutable destination file upon update, specifically when using the --archive option. A naive user would expect a verbatim one-to-one copy of his files to the destination, including all file characteristics like time, permissions, etc. For example, I use rsync to make file system backups to a secondary disk and I want the "schg" flags (e.g. on mandatory shared libraries) to be copied over cleanly, regardless of an already existing flag on the destination. In that respect, --perm and --flags currently follow a different paradigm. Which is a POLA violation IMHO.