DO NOT REPLY [Bug 3277] [Feature req] "I couldn't do something you asked" warning

bugzilla-daemon at dp3.samba.org bugzilla-daemon at dp3.samba.org
Mon Jan 30 21:36:23 GMT 2006


https://bugzilla.samba.org/show_bug.cgi?id=3277





------- Comment #7 from hashproduct at verizon.net  2006-01-30 14:36 MST -------
(In reply to comment #6)
> Yes -- I would.  I do a lot of copying where I want the permissions and groups
> copied exactly from the source.

If you care about the permissions and the groups, I bet you would want to be
warned if there were an owner or a group rsync couldn't preserve.  If so, ask
for behavior #2 by using -s.

> I believe you could change the (custom) -E option in that option set into a -p
> and it would behave the same way (due to how X works in the chmod option and
> the fact that you are forcing the read and write bits on).

I want permissions for existing files unchanged, and I want permissions for new
files masked by destination default permissions; those are the opposites of the
two behaviors that -p activates.

The sole purpose of the --chmod=ugo=rwX is to render ineffectual the AND-ing
with source permissions for new files.  The files come over the wire with 666
or 777 permissions, and the receiver ANDs that with destination default
permissions; that way, a file copied from a private area to a public one can
gain permissions.

For exactly the same reason, I create my tar packages with embedded 666 or 777
permissions using tar --mode=ugo=rwX.  I see it as discourteous to embed other
permissions because that second-guesses the intent of the person extracting the
archive.  I ranted about this on the bug-tar list a while ago, and then the
embedded permissions in kernel source tarballs mysteriously changed from
644/755 to 666/777; I speculate that I may have been the reason.  Enough
digression.

In the rare event that an existing file changes executability on the source, I
want the same to happen on the destination.  That is the purpose of my custom
-E, which affects only existing files.  Subversion set a precedent of
considering a file's executability to be as essential a counterpart to its
logical data as its modtime, even though executability is (unfortunately)
encoded in file security settings.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


More information about the rsync mailing list