Bug 5040 - multiple mount point directory sources aren't completely recursive
Summary: multiple mount point directory sources aren't completely recursive
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.0
Hardware: x86 Other
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2007-10-24 17:28 UTC by Aaron Pelton
Modified: 2008-07-26 10:16 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Pelton 2007-10-24 17:28:47 UTC
OS: SCO 5.0.6a

maybe relevant, maybe not: compiled with iconv enabled but receive an error:
iconv_open cannot open conversion file /usr/lib/nls/conv/_

trying to compile after configure --disable-iconv fails:
Undefined                       first referenced
 symbol                             in file
iconvbufs                           log.o

which is due to ICONV_CONST still being defined

actual problem:

/usr/local/bin/rsync  --temp-dir=/usr3/tmp -v --progress --bwlimit=100 --no-blocking-io -a -R --delete --force -x --exclude='/usr3/online_data/**' --exclude='/usr3/tmp/**' /usr2 /usr3 dbbu:

results in /usr2 having it's subdirectories (/usr2/me, /usr2/you, /usr2/somebodyelse) but nothing below them. /usr3 appears to be normal.

both /usr2 and /usr3 are mount points but the -x is intended to prevent mount points below them from being copied and what puzzles me is one works and one doesn't. Specifying top level non-mount points appears to work normally.

As you would expect, swapping usr2 and usr3 means usr2 works properly and usr3 gets just the top level dirs.

I sincerely hope this is a SCO issue and not worth resolving, but on the off chance it's otherwise an issue, I'm bothering to make a report. Forgive me if I missed something in the doc's, I did check!
Comment 1 Wayne Davison 2007-10-29 15:49:42 UTC
I'll be checking this next...
Comment 2 Wayne Davison 2007-10-29 21:39:58 UTC
I fixed the build problem late last week.

I just checked-in a fix for --on-file-system (-x) handling that I believe will fix the copy problem you reported.

Thanks for your report!