Not preserving permissions really preserves some

tim_smithers at tim_smithers at
Wed Jan 8 04:09:00 EST 2003

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 :-)

   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.
     - Tim

>To:    tim_smithers at
>cc:    rsync at
>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
>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 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

More information about the rsync mailing list