Bug 6240 - rsync 3.0.x -x/--one-file-system regression?
Summary: rsync 3.0.x -x/--one-file-system regression?
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.6
Hardware: x64 Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2009-03-31 18:37 UTC by Michael Jennings
Modified: 2009-04-02 19:32 UTC (History)
0 users

See Also:

The one-word fix for the issue (406 bytes, patch)
2009-03-31 22:30 UTC, Wayne Davison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Jennings 2009-03-31 18:37:13 UTC
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.


# 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)

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/
    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.
Comment 1 Michael Jennings 2009-03-31 18:40:05 UTC
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).
Comment 2 Wayne Davison 2009-03-31 22:29:45 UTC
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!
Comment 3 Wayne Davison 2009-03-31 22:30:49 UTC
Created attachment 4041 [details]
The one-word fix for the issue

This fixes the issue in both 3.0.6dev and 3.1.0dev.
Comment 4 Michael Jennings 2009-04-01 14:31:42 UTC
Applied patch to 3.0.5 and re-ran test case.  The problem is indeed resolved.

Thanks for the quick fix!

Comment 5 Michael Jennings 2009-04-02 19:32:34 UTC
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.