1 Jan 2003 16:13
RE: am I missing something, or are permissions always preserved?
Green, Paul <Paul.Green <at> stratus.com>
2003-01-01 15:13:32 GMT
2003-01-01 15:13:32 GMT
Ben [mailto:bench <at> tukati.com] > I'm relatively new to rsync, but it seems to me that if there's an > option to perserve permissions and you don't set it, then rsync > shouldn't do anything with permissions. Sounds good, but recall how POSIX / Unix system calls work. To create a file, you have to specify what mode (permission) it should have. There is no way to tell creat() or open() to "do the default thing." I think a case could be made that this is a defect / incompatibility in the underlying file system layer that issues complaints about permissions. Before I attempted to code any kind of a fix, I'd sure want to read the specs of this layer and understand how the designers thought this problem should be approached. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. Speaking from Stratus not for Stratus -- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
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.
RSS Feed