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 -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html