This seems very similar to bug#2645 rsync 3.0.4 and 3.0.6 server-side do not seem to honor the -x option. Reproducer: # mkdir /testing # mount -t tmpfs -o size=1M,nr_inodes=1000,mode=0700 tmpfs /testing # touch /testing/{a,b,c,d,e} # mkdir /testing/foo # mount -t tmpfs -o size=1M,nr_inodes=1000,mode=0700 tmpfs /testing/foo # touch /testing/foo/{a,b,c,d,e} # mkdir /tmp/moo # cd /tmp/moo # touch a b c d e # rsync -Havx --delete . /testing/ sending incremental file list ./ deleting foo/e deleting foo/d deleting foo/c deleting foo/b deleting foo/a rsync: delete_file: rmdir(foo) failed: Device or resource busy (16) a b c d e sent 258 bytes received 110 bytes 736.00 bytes/sec total size is 0 speedup is 0.00 [root@io006 moo]# rsync --version rsync version 3.0.5 protocol version 30 Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, no symtimes rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. Unless I'm missing something, -x should be honored by the server and should refuse to cross the /testing/foo mountpoint to delete the files contained on the 2nd RAMdisk.
Sorry, that should've said 3.0.4 and 3.0.5. I have not tested 3.0.6 or 3.1 (which have not yet been released AFAIK).
This was a very simple fix: receiver-side directories were not being marked with a content-dir flag, so the mount-marking code was ignoring the mount differences. I've checked in a fix that will go out in 3.0.6. Thanks for the test case -- that made duplicating the issue a breeze!
Created attachment 4041 [details] The one-word fix for the issue This fixes the issue in both 3.0.6dev and 3.1.0dev.
Applied patch to 3.0.5 and re-ran test case. The problem is indeed resolved. Thanks for the quick fix!
Is this something that could be added to the test suite? I notice that this behavior has come up and been fixed before, albeit with a different cause and solution. But since regression on the -x behavior can very easily result in data loss (as seen here), it might be useful to check for that.