Not preserving permissions really preserves some

[tim_smithers at mlc.com.au]

Thanks for the reply.

I did see this on the to-do list, and thought that it might
be a preferable solution (just a bit more work).
It would be messy to do the xargs stuff as I am running rsync
over ssh with restricted commands based upon keys :-)

Questions:
   1. Is the proposed solution in the todo (--chmod) agreed?
   2. Is anyone actively working on it?
   3. If I wrote the patch to support the --chmod as outlined
      in the todo file, would someone apply it (assuming my
      code was okay ;-) ?
   4. Should the patch be applied to the "head", or should it
      be against the latest release version?

Thanks in advance.
Regards,
     - Tim


>To:    tim_smithers at mlc.com.au
>cc:    rsync at lists.samba.org
>Subject:       Re: Not preserving permissions really preserves some
>
>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
>>