am I missing something, or are permissions always preserved?

[jw schultz]

On Tue, Dec 31, 2002 at 08:06:52AM -0800, Ben wrote:
> No, these are for new files. Existing files work perfectly, but, like
> you said before, for new files rsync creates the file then attempts to
> alter the permissions based on the origional permissions and umask. 
> 
> > On Mon, Dec 30, 2002 at 06:44:24PM -0800, Ben wrote:
> > > Hmmm... while that makes sense, that doesn't really help me in my
> > > situation, where permissions cannot be altered because of the network
> > > mount they are being written to.
> > > 
> > > Does it make sense to impliment a "don't touch permissions" flag?
> > > 
> > > On Tue, 2002-12-24 at 05:08, Dave Dykstra wrote:
> > > > 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?

For what kind of mount does chmod fail?  Must be the
filesystem.  If this is a common condition it might be worth
reducing the warnings.  I'm going to assume for the moment
that this condition is not so unusual as to require
ignoring.  Generating a error for every new file is ugly.

What is the actual errno?  If we can create the file but not
change its perms this should be producing a strange errno;
perhaps EINVAL or EROFS.  If so we could check for that and
cope.  Perhaps output only one warning but otherwise treat
it as if success with very little overhead for the normal
case.

Something like (assuming EINVAL):
|	static int fs_has_perms = 1;

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

That would output the warning message only once without
treating it as an error and wouldn't slow things down (beyond
I-cache condsiderations) when it does't happen.

This approach would require that the errno be one that
couldn't happpen otherwise but saves us adding an option
that would mostly cause confusion.  This does have the
disadvantage of making failed chmod calls.  If this case is
common enough then we could move the fs_has_perms test to
|        if (st->st_mode != file->mode) {
but i don't like the idea of slowing down the common case.




-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt