Status of --ignorcase option in main tree/build?

Matt McCutchen matt at
Sat May 17 15:16:28 GMT 2008

On Sat, 2008-05-17 at 01:32 -0400, Aaron Davies wrote:
> How does this work on OS X/HFS+ (case-preserving, but
> case-insensitive)? Any issues with the standard build in a mixed-OS
> scenario like this?

The standard version should work mostly fine on a case-insensitive,
case-preserving filesystem.  The major issue is in the behavior with a
source file and a destination file that differ only in case (say foo and

* If you don't use a --delete mode, rsync will find foo already present
on the destination due to the case insensitivity and won't change

* If you use --delete-before or --delete-during, rsync will delete FOO
as extraneous and then copy foo.  The overall effect is to
(inefficiently) update the case of destination files, which may be
desirable.  If you change the case of a destination file by hand to work
around case sloppiness in a program (see ) and don't want
rsync to reverse your change, you can use a protect filter to block the
individual deletion.

* If you use --delete-delay or --delete-after, rsync will find foo
present and then delete FOO, leaving you with no destination file at
all, so don't use --delete-delay or --delete-after.

With --ignore-case, the patched version of rsync will leave FOO alone
regardless of the delete mode.  --ignore-case also makes filter matching

Note that HFS+'s behavior of automatically decomposing UTF-8 characters
in filenames presents analogous issues when source files whose names
contain composed UTF-8 characters are copied to an HFS+ destination.  To
work around this problem, pass --iconv=UTF-8,UTF8-MAC for a local copy
or push, or --iconv=UTF8-MAC,UTF-8 for a pull.


More information about the rsync mailing list