is support for non-ASCII filenames in rsync complete?

[Matt McCutchen]

On Mon, 2010-09-20 at 08:55 +1200, Jason Haar wrote:
> Over the years there's been many people saying how files with non-ASCII
> charsets got their filenames "corrupted" moving between different
> systems. So I'm wondering what the current state is with rsync-3.06+?
> 
> ie I want to use rsync-3.06+ to backup WinXP+ (and MacOS?) filesystems
> by using native versions of rsync clients to a remote Linux-based rsyncd
> process. If I do that, should I expect that our Chinese,French,etc users
> will have their backups with the correct filenames?
> 
> As far as I'm aware, everything is UTF8 these days, so I shouldn't
> expect any issues? eg I shouldn't have to use the "--iconv" option (all
> this language-specific stuff gives me a headache ;-)

"Is support for non-ASCII filenames in rsync complete?" is a misleading
question.  Traditionally, rsync has always preserved filenames as byte
strings and has never dealt with encoding issues, like most unix file
manipulation tools.  "Corruption" is uniformly the result of different
applications interpreting those byte strings in different encodings or
of conversions performed by OSes, OS emulation layers, or filesystems.
The --iconv option is now offered as one way to work around some of
those issues.

Whether the destination filenames will be perceived as correct by your
users depends on any conversions performed by Windows, Cygwin, or Mac OS
as well as the method used to browse or restore backups, if it is other
than an rsync in the reverse direction.  Most likely you're right that
there will be no problems because everything uses UTF-8, but if there
are, strictly speaking it isn't rsync's fault.  You can always do a test
and see if the results are what you want.

-- 
Matt