rsync - Dec 2002 - am I missing something, or are permissions always preserved?

They seem to be for me, even when I don't pass in the --perms flag. This
is a problem because I'm rsyncing to a samba mount with fixed
permissions.

Looking at rsync.c (for version 2.5.5) starting at line 204, I see this
code snippet:

#ifdef HAVE_CHMOD
    if (!S_ISLNK(st->st_mode)) {
        if (st->st_mode != file->mode) {
            updated = 1;
            if (do_chmod(fname,file->mode) != 0) {
                rprintf(FERROR,"failed to set permissions on %s :
%s\n",
                    fname,strerror(errno));
                return 0;
            }
        }
    }
#endif

I would have expected to see a test for the setting of perserve_perms,
but it's not there. Is this a bug or is there there a reason
perserve_perms isn't checked?

When preserve_perms is not set, rsync sets a default permission based on
the original permissions and the umask.  A comment in flist.c says that is
what GNU cp does, so that's why rsync does it.   Comments in generator.c
and receiver.c indicate that if a file already exists and preserve_perms
isn't set, the original permissions should be preserved.

- Dave

On Sat, Dec 21, 2002 at 12:30:55PM -0800, Ben wrote:
> They seem to be for me, even when I don't pass in the --perms flag.
This
> is a problem because I'm rsyncing to a samba mount with fixed
> permissions.
> 
> Looking at rsync.c (for version 2.5.5) starting at line 204, I see this
> code snippet:
> 
> #ifdef HAVE_CHMOD
>     if (!S_ISLNK(st->st_mode)) {
>         if (st->st_mode != file->mode) {
>             updated = 1;
>             if (do_chmod(fname,file->mode) != 0) {
>                 rprintf(FERROR,"failed to set permissions on %s :
%s\n",
>                     fname,strerror(errno));
>                 return 0;
>             }
>         }
>     }
> #endif
> 
> I would have expected to see a test for the setting of perserve_perms,
> but it's not there. Is this a bug or is there there a reason
> perserve_perms isn't checked?
> 
> -- 
> To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Ben [mailto:bench@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

On Sat, Jan 11, 2003 at 11:19:33AM -0800, Ben wrote [off
list]:
> On Tue, 2003-01-07 at 14:49, Dave Dykstra wrote:
> > That sounds reasonable to me that rsync shouldn't try to preserve
those
> > extra bits without -p.  Try making a patch and seeing if that works.
> > 
> > I don't have Samba set up, but on a vfat filesystem on Linux rsync
is
> > doing even worse because after the initial file creation it does a
> > "fchmod(fd, 0600)" which fails and it doesn't even copy
files at all.
> > 
> 
> 
> Okay, attached is a patch I just whipped up that seems to work well. It
> adds the --skip-perms flag, which has the effect of making rsync not try
> to set permissions, not even to sane values.
I was not able to read your patch because it seems to have lots of
characters that I can't view on my email reader.  A header on the
attachment says
    X-MIME-Autoconverted: from 8bit to base64 by mx6.mx.voyager.net
so my ISP must have had trouble with it.

Anyway, I wasn't thinking of an option, I was thinking of it doing
something that was the default whenever there was no -p.  I'd rather
avoid adding an option if we can get away with it.  I'm now having second
thoughts about stripping off the setuid/setgid bits by default without
'-p', because that's not what GNU cp does.  I think it would be
better if
it just silently ignored errors from chmod and fchmod when -p is not set.

- Dave