Bug 3988 - -a collides with --flags
-a collides with --flags
Status: VERIFIED FIXED
Product: rsync
Classification: Unclassified
Component: core
2.6.8
x86 FreeBSD
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-02 09:13 UTC by Helge Oldach
Modified: 2006-10-16 02:38 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Helge Oldach 2006-08-02 09:13:39 UTC
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 .
#
Comment 1 Alex 2006-09-24 16:25:22 UTC
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?
Comment 2 Wayne Davison 2006-10-15 13:06:18 UTC
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.
Comment 3 Helge Oldach 2006-10-15 17:08:57 UTC
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?
Comment 4 Matt McCutchen 2006-10-15 17:35:38 UTC
(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.
Comment 5 Helge Oldach 2006-10-16 00:30:05 UTC
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]
# 
Comment 6 Wayne Davison 2006-10-16 02:11:41 UTC
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.
Comment 7 Helge Oldach 2006-10-16 02:38:18 UTC
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.