Bug 5792 - rsync fails to log files "sent" with options: --itemize-changes -n --log-file
rsync fails to log files "sent" with options: --itemize-changes -n --log-file
Status: ASSIGNED
Product: rsync
Classification: Unclassified
Component: core
3.0.2
PPC Mac OS X
: P3 minor
: ---
Assigned To: Matt McCutchen
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-24 11:38 UTC by Denis Laplante
Modified: 2009-03-24 07:54 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Denis Laplante 2008-09-24 11:38:10 UTC
I find a discrepancy between screen output and log file output when running rsync (version 3.0.2 via macports on MacOsX-10.4 PPC) in dry-run mode.
I find no discrepancy when I omit the "-n" option.  The screen listing seems correct with/without "-n", as well as files copied.

/opt/local/bin/rsync -n -i --stats -aES -x --exclude-from ${EXCL_FILE} --log-file=${LOG_FILE} / /Volumes/${BACKUP_DISK}

Missing from the LOG_FILE copy are all the files that would have been sent (prefixed with ">").
Below are 6 consecutive lines from screen output of above command - only the last line appears in ${LOG_FILE}:

>f+++++++++ .hotfiles.btree
>f..t...... .Spotlight-V100/.journalHistoryLog
>f..t...... .Spotlight-V100/.store.db
>f..t...... .Spotlight-V100/ContentIndex.db
>f..t...... .Spotlight-V100/store.db
.d..t...... Library/Caches/

This combination of options is important to me while debugging a script to backup my system.  I next plan to use the MacOsX "bless" command on the backup filesystem to make it bootable.  Note that the latest MacOsX-10.5 supplies version 2.6.9 (2006) of rsync, which is unsuitable for Mac "resource forks" in incremental mode and lacks bug fixes and useful features.

VERSION: /opt/local/bin/rsync --version
rsync  version 3.0.2  protocol version 30
Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 32-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, no symtimes

Not tested on any other hardware or software.
Comment 1 Matt McCutchen 2008-09-24 15:20:06 UTC
I can reproduce the described behavior with the latest development rsync on Linux: in dry-run mode, the log file seems to contain all itemize entries except for regular file transfers (first character >).  With rsync 2.6.9, the log contains no itemize entries at all.

What is the expected behavior here?  I know that the client's stdout is supposed to be the same as on a real run and a daemon's log is supposed to record only what actually happened (i.e., nothing on a dry run), but I'm not familiar with the expected behavior for a client log file.  That should probably be documented in the man page description of --log-file.
Comment 2 Wayne Davison 2008-10-02 14:07:38 UTC
The current code logs the same way for a --log-file as it does for a daemon log, which means that it does not log transfers that aren't really transfers.  You can instead use --out-format to change what rsync outputs, and the output will be consistent in dry-run mode with the normal-mode output.
Comment 3 Matt McCutchen 2008-10-02 20:07:29 UTC
What is the justification for a client log file containing all itemize lines *except* regular file transfers?  If it is to be consistent with a daemon, I would expect to see no itemize lines at all on a dry run.

Whatever the expected behavior is, it should be documented in the man page.  The man page does say that --log-file is "similar to the logging that a daemon does".  Thus, it might suffice to state in the description of "transfer logging" in rsyncd.conf(5) that nothing is logged on a dry run.
Comment 4 Wayne Davison 2008-10-03 00:36:39 UTC
.