Hi All,
I have had reports of problems with the -R option on OSX 10.6.4.
Just tested it myself and found this odd result:
When I run this
"dtruss -f path/to/rsync -aHAXNR --fileflags --force-change
--protect-decmpfs --stats -v /Users/astrid/Documents/main.m
/Users/astrid/Desktop/rrr
it produces the expected results with the relative folder paths in place
/Users/astrid/Desktop/rrr/Users/astrid/Desktop/main.m
but copying file from Desktop itself
"dtruss -f path/to/rsync -aHAXNR --fileflags --force-change
--protect-decmpfs --stats -v /Users/astrid/Desktop/main.m
/Users/astrid/Desktop/rrr
/Users/astrid/Desktop/rrr/Users/astrid/
empty!
Oddly, it works fine from a clone of this system (cloned a few weeks ago) and on
OSX 10.5.
Any thoughts appreciated.
Thanks, Rob
Here are the first few lines from running dtruss on rsync
rsync: unpack_smb_acl: sys_acl_get_info(): Unknown error: 0 (0)
rsync error: some files/attrs were not transferred (see previous errors) (code
23) at main.c(1044) [sender=3.0.7]
PID/THRD SYSCALL(args) = return
609/0x11a0: sigaction(0x1E, 0xBFFFF5A0, 0x0) = 0 0
609/0x11a0: sigaction(0x1F, 0xBFFFF5A0, 0x0) = 0 0
609/0x11a0: sigaction(0x14, 0xBFFFF5A0, 0x0) = 0 0
609/0x11a0: geteuid(0x14, 0xBFFFF5A0, 0x0) = 0 0
609/0x11a0: umask(0x0, 0xBFFFF5A0, 0x0) = 18 0
609/0x11a0: open("/etc/popt\0", 0x0, 0x8FE44840) = -1 Err#2
609/0x11a0: open("/Users/astrid/.popt\0", 0x0, 0x0) = -1 Err#2
note: (It cuts off at "/astrid/ and no files are copied after that point)
609/0x11a0: sigaction(0x2, 0xBFFFF5A0, 0x0) = 0 0
609/0x11a0: sigaction(0x1, 0xBFFFF5A0, 0x0) = 0 0
609/0x11a0: sigaction(0xF, 0xBFFFF5A0, 0x0) = 0 0
609/0x11a0: sigprocmask(0x2, 0xBFFFF5FC, 0x0) = 0x0 0
609/0x11a0: sigaction(0xD, 0xBFFFF5A0, 0x0) = 0 0
609/0x11a0: sigaction(0x19, 0xBFFFF5A0, 0x0) = 0 0
Hi again, Problem solved Sorry. I didn't even think to check permissions on the Desktop folder, the first logical thing to check. Somehow they had been changed. Fixed them and -R works fine now. I believe other users are likely having permissions issues too. Thanks, Rob
>> I have had reports of problems with the -R option on OSX 10.6.4. >> >> Just tested it myself and found this odd result: >> >> When I run this >> >> "dtruss -f path/to/rsync -aHAXNR --fileflags --force-change --protect-decmpfs --stats -v /Users/astrid/Documents/main.m /Users/astrid/Desktop/rrr >> >> it produces the expected results with the relative folder paths in place >> >> /Users/astrid/Desktop/rrr/Users/astrid/Desktop/main.m >> >> but copying file from Desktop itself >> >> "dtruss -f path/to/rsync -aHAXNR --fileflags --force-change --protect-decmpfs --stats -v /Users/astrid/Desktop/main.m /Users/astrid/Desktop/rrr >> >> /Users/astrid/Desktop/rrr/Users/astrid/ > > > Problem solved > > Sorry. I didn't even think to check permissions on the Desktop folder, the first logical thing to check. Somehow they had been changed. Fixed them and -R works fine now. I believe other users are likely having permissions issues too.I have made the same mistake myself and have had the issue reported to me on multiple occasions in the past. This is why LBackup now checks the permissions are enabled on the destination volume. Perhaps when rsync runs on OS X systems it should default to a mode where a permissions are enabled check is performed on the destination volume and then a warning could be reported if they are not enabled? Just a possibility to avoid many more people having this same issue? Quoted below is an example of the output from LBackup when the permissions on a destination drive is not enabled :> WARNING! : Permissions are disabled on backup destination volume. > It is recommended that permissions on the destination volume are enabled. > Failure to enable permissions will most likely result in the hard link system failing. > Permissions may be enabled by issuing the following command as root : > /usr/sbin/vsdbutil -a "/Volumes/volume_name"Perhaps adding something like this directly into rsync is a good idea for Mac OS X users? Any comments? --------------------------------------------------------------------- This email is protected by LBackup, an open source backup solution. http://www.lbackup.org