rsync - Jan 2006 - DO NOT REPLY [Bug 3430] New: Error with ACL-patch and -x on mountpoint

https://bugzilla.samba.org/show_bug.cgi?id=3430

           Summary: Error with ACL-patch and -x on mountpoint
           Product: rsync
           Version: 2.6.6
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: minor
          Priority: P3
         Component: core
        AssignedTo: wayned@samba.org
        ReportedBy: samba-bugs@digital-trauma.de
         QAContact: rsync-qa@samba.org


Hi,

using rsync-2.6.6 with ACL patch on two freebsd systems (with dirvish) and the
options -x and --acls, we get the following error:

send_acl: sys_acl_get_file(mayerr/test, SMB_ACL_TYPE_ACCESS): Operation not
supported

and so on for 3 more cycles.

Rsync is right about the fact that this SMB share mount point doesn't
support
acls, but I still wonder why it even tries to access it with the -x option.

As far as I can tell the backups still work, but having those errors all over
the logs isn't nice.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3430





------- Comment #1 from hashproduct@verizon.net  2006-01-20 10:06 MST -------
The issue is that, when rsync detects that a directory is on another
filesystem, it sends the directory itself but skips the contents.  See
send_directory in flist.c: it reads all the directory entries into the file
list, sends them all (possibly including ones on other filesystems), and then
calls send_if_directory on each one to recurse into those that is in fact on
the same filesystem.

I'm inclined to fix this by moving the test for being on the same filesystem
into the readdir loop of send_directory, but there seem to be a lot of
subtleties to rsync's recursion, so I don't know if this will work. 
Thoughts?


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3430


wayned@samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #2 from wayned@samba.org  2006-01-20 10:54 MST -------
(In reply to comment #1)
> I'm inclined to fix this by moving the test for being on the same
> filesystem into the readdir loop of send_directory
No, we copy the mount-point directory on purpose because we want it to be there
should the remote system need to mount their own filesystem at that point.

The right fix is to eliminate this ACL error altogether: rsync should never
complain about a source item not having ACL info; it should just copy the item
without ACL info.  (This is one of the things that must be fixed before the ACL
patch can make it into the released version of rsync.)


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3430





------- Comment #3 from hashproduct@verizon.net  2006-01-20 11:57 MST -------
(In reply to comment #2)
> No, we copy the mount-point directory on purpose because we want it to be
there
> should the remote system need to mount their own filesystem at that point.
True, in some cases it might be useful to copy the mount point, but the empty
folder on the destination might confuse someone about whether the filesystem
was excluded or empty or what.  I don't think it makes sense to copy the
mount
point unless we know the true attributes of the mount point itself as opposed
to those overlaid on it by the mounted filesystem.

For example, on my computer, I set 000 permissions on directories intended to
be used as mount points, and then the permissions are overlaid with those of
the root of the mounted filesystem.  That way, it's easy to see whether the
filesystem is mounted, and mistakes like backing up the system to
/media/external-disk when the disk isn't mounted are avoided.  If rsync were
to
copy those mount points, I would expect to see their underlying 000 permissions
on the destination, not the permissions of the top of the mounted filesystem.
> The right fix is to eliminate this ACL error altogether: rsync should never
> complain about a source item not having ACL info; it should just copy the
item
> without ACL info.  (This is one of the things that must be fixed before the
ACL
> patch can make it into the released version of rsync.)
Yes, that should be done no matter how rsync treats mount points.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3430





------- Comment #4 from wayned@samba.org  2006-01-20 13:02 MST -------
I know of no way to find the attributes of the underlying mount-point directory
when the mount is present.  And leaving out the mount-point dir is not an
improvement in my book.  I also wouldn't want to tweak the permissions of a
mount-point dir to an arbitrary value because the destination filesystem might
have a real directory there, and we wouldn't want to adversely affect its
permissions.

We could make this user-selectable by letting the user repeat the -x option to
choose to eliminate the mount-point dirs from the transfer.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3430





------- Comment #5 from hashproduct@verizon.net  2006-01-20 13:43 MST -------
(In reply to comment #4)
> We could make this user-selectable by letting the user repeat the -x option
to
> choose to eliminate the mount-point dirs from the transfer.
In fact that was just what I was going to suggest.  When in doubt, add an
option!  :)


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3430





------- Comment #6 from hashproduct@verizon.net  2006-01-20 15:03 MST -------
Created an attachment (id=1704)
 --> (https://bugzilla.samba.org/attachment.cgi?id=1704&action=view)
Makes -x -x exclude mount points themselves

This patch should do it.  Very casual testing (rsync -n --exclude=/*/*/** /
test/ with varying amounts of -x) suggests that it works.

I noticed that, when --copy-links or --copy-unsafe-links is enabled, rsync will
follow cross-filesystem symlinks to nondirectories but not to directories. 
This behavior seems strange, but I didn't change it.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3430





------- Comment #7 from samba-bugs@digital-trauma.de  2006-01-21 09:16 MST
-------
AFAIK, other tools that have a don't-traverse-file-systems option (find, du,
..) in the unix world ignore the mount point (as it logically belongs to the
fs you don't want to traverse to), that's why I was surprised rsync
didn't. But
I guess I could live with a non-default option, too.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3430





------- Comment #8 from hashproduct@verizon.net  2006-01-21 13:35 MST -------
Created an attachment (id=1705)
 --> (https://bugzilla.samba.org/attachment.cgi?id=1705&action=view)
Suggested changes to man page for --one-file-system

Wayne seems to have expanded the documentation of -x in the man page to take
into account -x -x and other issues, but I would like to suggest some further
changes that I hope will make the man page clearer.  At the very least, the old
section about -x should be deleted.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=3430


wayned@samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




------- Comment #9 from wayned@samba.org  2006-01-29 01:35 MST -------
Rsync now supports -xx to avoid including empty mount-point directories in the
transfer.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.