Not preserving permissions really preserves some

[Dave Dykstra]

I would object to that because it would change existing functionality
(emulating GNU cp) and isn't general enough.  We've discussed a possible
general manipulation of permissions; see
    http://lists.samba.org/pipermail/rsync/2002-March/006477.html

Alternatively, you could process the output of the -v option and run
xargs chmod on all files that have been touched.

- Dave Dykstra

On Thu, Jan 02, 2003 at 12:47:18PM +1100, tim_smithers at mlc.com.au wrote:
> 
> This appears to be a feature :-)
> 
> I'm running rsync 2.5.5 on Solaris 8, and testing transferring
> files between two boxes with permission preservation turned *off*.
> 
> I have three files:
> 
> 700 with permissions 700
> 770 with permissions 770
> 777 with permissions 770
> 
> The umask for the target system is set to: 007
> [I have checked this via prints from the rsync code]
> 
> When the files get transferred, the permissions are:
> 
> 700 -> permission 700
> 770 -> permission 770
> 777 -> permission 770
> 
> This retains the permissions from the group part of the file 700.
> That is, even though my umask wants the group set, it doesn't
> get set.
> 
> Why this is a problem for me:
> 
> I don't trust the source system to get the permissions correct
> (it's a windows box running cygwin), and I want to force a set
> of permissions so the process using the synched directory will
> be able to access it (through group permissions).
> 
> Suggested solution:
> 
> I don't think changing the way permissions are created would be
> that backward-compatible, so maybe a new option?
> 
> Create an option: --ignore-permissions
> 
> in receive_file_entry(), in filelist.c
> 
> 
> ========== code block ====================
> if (!preserve_perms) {
>     extern int orig_umask;
>     /* set an appropriate set of permissions based on original
>        permissions and umask. This emulates what GNU cp does */
> 
>        file->mode &= ~orig_umask;  <-- change this to line below
> 
>        file->mode = ((ignore_perms?0:0666) | file->mode) & ~orig_umask;
> }
> 
> I used 0666 for the mask to pick up the execute bit (otherwise might
> screw up creating directories we can go down).
> 
> 
> I would be interested in any feedback on this problem from the maintainers.
> If there is any agreement on how it might be addressed and included in a
> new version, then I am happy to create all of the patch files and test it
> for submission to a maintainer.
> 
> If any replies to the list could also cc my reply address, that would
> be appreciated.
> 
> Regards,
>     - Tim
> 
> 
> 
> 
> 
> The information contained in this e-mail communication may be confidential.
> You should only read, disclose, re-transmit,copy, distribute, act in
> reliance on or commercialise the information if you are authorised to do
> so. If you are not the intended recipient of this e-mail communication,
> please immediately notify us by e-mail to postmaster at mlc.com.au, or reply
> by e-mail direct to the sender and then destroy any electronic and paper
> copy of this message.
> 
> Any views expressed in this e-mail communication are those of the
> individual sender, except where the sender specifically states them to be
> the views of a member of the National Australia Bank Group of companies.
> 
> The National Australia Bank Group of companies does not represent, warrant
> or guarantee that the integrity of this communication has been maintained
> nor that the communication is free of errors, virus or interference.
> 
> -- 
> To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html