The Samba-Bugzilla – Bug 3430
Error with ACL-patch and -x on mountpoint
Last modified: 2006-03-12 02:56:57 UTC
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.
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?
(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.)
(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.
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.
(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! :)
Created attachment 1704 [details]
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.
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.
Created attachment 1705 [details]
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.
Rsync now supports -xx to avoid including empty mount-point directories in the transfer.