Axel Essbaum
2009-Jul-03 20:45 UTC
Bug? backup_dir sometimes reported on STDOUT, sometimes not.
Running rsync 3.0.6 on OS X 10.5.7 (on a MacBook Pro) and using the -b flag (and -v --verbose), the "backup_dir" is reported in the output, but sometimes on STDOUT and sometimes somewhere else. Note that the rsync daemon running on the "server" is 2.6.9 (on another MacBook Pro, OS X 10.5.7) For example, in bash, this happens: axe-MBP:bin work$ /usr/local/bin/rsync -aub --dry-run -v --verbose -- exclude '*~' --backup-dir=/Users/work/Desktop/Heart_and_Soul/backup/ joe@Joe-MBP.local :/Users/joe/Desktop/Heart_and_Soul/ /Users/work/Desktop/ Heart_and_Soul/ > /dev/null axe-MBP:bin work$ (all output goes to STDOUT and is redirected to /dev/null) But by swapping the input and output directories, this happens: axe-MBP:bin work$ /usr/local/bin/rsync -aub --dry-run -v --verbose -- exclude '*~' --backup-dir=/Users/work/Desktop/Heart_and_Soul/backup/ / Users/work/Desktop/Heart_and_Soul/ joe@Joe-MBP.local:/Users/joe/ Desktop/Heart_and_Soul/ > /dev/null backup_dir is /Users/work/Desktop/Heart_and_Soul/backup/ axe-MBP:bin work$ In the second case the "backup_dir" report in the output is apparently not on STDOUT. I'm trying to parse/postprocess rsync's STDOUT but let STDERR come through untouched, and I notice that half the time I get this spurious backup_dir line that's not redirected with the rest of the STDOUT. - Axel -- Axel Essbaum axel@essbaum.com
Wayne Davison
2009-Jul-04 16:50 UTC
Bug? backup_dir sometimes reported on STDOUT, sometimes not.
On Fri, Jul 03, 2009 at 10:46:13PM +0200, Axel Essbaum wrote:> In the second case the "backup_dir" report in the output is apparently > not on STDOUT.In all versions of rsync prior to 3.1.0 (which is not yet released), the "backup_dir is ..." message is output very early in the transfer, so a remote rsync cannot send it over the protocol (since it is not yet setup right for messages). It instead sends it via STDERR (since STDOUT is being used to talk to the client rsync). 3.1.0 fixes this by moving this output later in the sequence of events, allowing the message to come through the protocol and go to STDOUT as expected. You have several options: - Don't use double verbosity, and the message won't be output at all. If you want to see unchanged files, you can try -ii as an alternative way to get that info (though it does show even attribute changes, and you'd need to be able to parse the new output format). - Use 3.1.0 -- it's in a stable state, and I'm hoping to get it released before too long. (I use it for all my rsyncing.) - Patch the remote rsync to move that output from options.c to main.c. (See the attached patch.) ..wayne.. -------------- next part -------------- A non-text attachment was scrubbed... Name: backup_dir.patch Type: text/x-diff Size: 1069 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20090704/e252f503/backup_dir.bin
Apparently Analagous Threads
- [Bug 11812] New: rsync without --verbose still writes "(new) backup_dir is ..." to STDOUT
- backup_dir problem
- Ensuring that rsync doesn't try to write to an unmounted drive
- Lookup another node's hiera data - fqdn hierarchy
- Ensuring that rsync doesn't try to write to an unmounted drive