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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED], 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
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
