Improved the re-copying FAQ item as Matt suggested.
authorWayne Davison <wayned@samba.org>
Tue, 1 Apr 2008 19:52:17 +0000 (19:52 +0000)
committerWayne Davison <wayned@samba.org>
Tue, 1 Apr 2008 19:52:17 +0000 (19:52 +0000)
FAQ.html

index d486727..7d0b21b 100644 (file)
--- a/FAQ.html
+++ b/FAQ.html
@@ -9,7 +9,7 @@
 
 <table><tr valign=top><td><ul>
 <li><a href="#1">the transfer fails to finish</a><br>
-<li><a href="#2">copies every file</a><br>
+<li><a href="#2">rsync recopies the same files</a><br>
 <li><a href="#3">is your shell clean</a><br>
 <li><a href="#4">memory usage</a><br>
 <li><a href="#5">out of memory</a><br>
@@ -41,7 +41,7 @@ rsync error: error in rsync protocol data stream (code 12) at io.c(342)
 for details on how you can try to figure out what is going wrong.
 
 <hr>
-<h3><a name=2>copies every file</a></h3>
+<h3><a name=2>rsync recopies the same files</a></h3>
 
 <p>Some people occasionally report that rsync copies every file when they
 expect it to copy only a small subset. In most cases the explanation is
@@ -51,19 +51,46 @@ changed (because the modified time and size do not match).
 
 <p>Another common cause involves sending files to an Microsoft filesystem:
 if the file's modified time is an odd value but the receiving filesystem
-can only even values, then rsync will re-transfer too many files.  You can
-avoid this by specifying the --modify-window=1 option.
+can only store even values, then rsync will re-transfer too many files.
+You can avoid this by specifying the --modify-window=1 option.
 
-<p>A third case happens can happen when daylight-savings time changes if
-your OS+filesystem saves file times in local time instead of UTC.  For a
-full explanation of this and some suggestions on how to avoid them problem,
-see <a href="daylight-savings.html">this
+<p>Yet another periodic case happens can happen when daylight-savings
+time changes if your OS+filesystem saves file times in local time
+instead of UTC.  For a full explanation of this and some suggestions on
+how to avoid them problem, see <a href="daylight-savings.html">this
 document</a>.
 
-<p>If you think that rsync is erroneously copying every file then look at
-the stats produced with -v and see if rsync is really sending all the data. 
-See also the --checksum (-c) option for one way to avoid the extra copying
-without synchronizing the modified times.
+<p>Something else that trips up rsync is if the filesystem changes the
+filename behind the scenes.  This can happen if a filesystem changes an
+all-uppercase name into lowercase, or if it changes decomposes UTF-8
+behind your back.
+
+<blockquote>
+
+<p>An example of the latter can occur with HFS+ on Mac OS X:  if you
+copy a directory with a file that has a UTF-8 character sequence in it,
+say a 2-byte umlaut-u (\0303\0274), the file will get stored by the
+filesystem using a single character for the umlaut-u (\0374), and rsync
+will not know that the file is the same (it will, in fact, remove the
+file if --delete is enabled, and then recreate it).
+
+<p>You can avoid a charset problem by passing an appropriate --iconv
+option to rsync that tells it what character set the source files are,
+and what character set the destination files get stored in.  For
+instance, the above Mac OS X problem would be dealt with by using
+--iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac
+OS X iconv in which all characters are decomposed).
+
+</blockquote>
+
+<p>If you think that rsync is copying too many files, look at the
+itemized output (-i) to see why rsync is doing the update (e.g. the 't'
+flag indicates that the time differs, or all pluses indicates that rsync
+thinks the file doesn't exist).  You can also look at the stats produced
+with -v and see if rsync is really sending all the data.  See also the
+--checksum (-c) option for one way to avoid the extra copying on files
+that don't have synchronized modified times (but keep in mind that the
+-c option eats lots of disk I/O, and can be rather slow).
 
 <hr>
 <h3><a name=3>is your shell clean</a></h3>