Bug 3430 - Error with ACL-patch and -x on mountpoint
Error with ACL-patch and -x on mountpoint
Status: CLOSED FIXED
Product: rsync
Classification: Unclassified
Component: core
2.6.6
Other FreeBSD
: P3 minor
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-20 07:16 UTC by Thomas R.
Modified: 2006-03-12 02:56 UTC (History)
0 users

See Also:


Attachments
Makes -x -x exclude mount points themselves (3.46 KB, patch)
2006-01-20 15:03 UTC, Matt McCutchen
no flags Details
Suggested changes to man page for --one-file-system (2.34 KB, patch)
2006-01-21 13:35 UTC, Matt McCutchen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas R. 2006-01-20 07:16:37 UTC
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.
Comment 1 Matt McCutchen 2006-01-20 10:06:04 UTC
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?
Comment 2 Wayne Davison 2006-01-20 10:54:48 UTC
(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.)
Comment 3 Matt McCutchen 2006-01-20 11:57:05 UTC
(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.
Comment 4 Wayne Davison 2006-01-20 13:02:29 UTC
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.
Comment 5 Matt McCutchen 2006-01-20 13:43:06 UTC
(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!  :)
Comment 6 Matt McCutchen 2006-01-20 15:03:00 UTC
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.
Comment 7 Thomas R. 2006-01-21 09:16:01 UTC
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.
Comment 8 Matt McCutchen 2006-01-21 13:35:04 UTC
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.
Comment 9 Wayne Davison 2006-01-29 01:35:55 UTC
Rsync now supports -xx to avoid including empty mount-point directories in the transfer.