rsyncでiconvオプションをつけると、deleteオプションの挙動が変わる？？(Mac)

[最終更新] 2016年9月15日

Mac版の話です。Macではファイルシステムの都合上、濁点が一文字扱いになってしまうため、他のOSのマシンにファイルをコピーするときは、文字コードに気をつけてやらないといけません。rsyncにおいてはiconvオプションを付ける必要があるのですが、どうも、これをつけるとdeleteオプションの挙動が変わってしまような感じです。

今回使ったソフトウェアは、MacのHomebrewでインストールした、rsync 3.0.9です。

MacをUnixマシンとして愛用する者の間では有名な仕様として悪名高い（？）UTF-8-MACがあります。Macでは濁点はそれだけで一文字として数えられるというもので、この仕様の為に、MacからLinuxマシンにscpやrsyncなどで濁点のつくファイルをコピーすると、たとえば「がぎぐげご.txt」が「か゛き゛く゛け゛こ゛.txt」となってしまいます。これが非常に厄介でして、何が厄介かというと、まずそのような仕様になっているなど最初は考えもしませんから、濁点問題というものに気づくのにまず時間がかかります。突然いくつかのファイルが見えなくなったりして、なんでだなんでだと調べている間にこの濁点問題に行き着くのです。ここに至るまでにけっこうなエネルギーを消費します。

解決方法として、MacからLinuxマシンにrsync転送時にはiconvオプションでUTF-8-MACをUTF-8にする、というものがあります。私もご多分に漏れずその解決方法を利用しているものです。具体的には、以下のようになります。

$ rsync --delete --iconv=UTF-8-MAC,UTF-8 -ave ssh ~/data/ hack_le@server:data/

このコマンドの意味は、ローカルの~/dataディレクトリの中身と、serverマシン(Linux)のhack_le~/data/の中身を同期させるというものです。その際、ファイル名をUTF-8-MACからUTF-8に変換しています。

ところが、上記のコマンドをそのまま入力すると、–deleteオプションが正しく機能しませんでした。あれれと思って色々検証したところ、どうやらiconvオプションを外すと、–deleteが正しく機能します。なぜそうなるのかはよくわかりません。あれこれやった挙句、対処法として、アスタリスクを付けるということで落ち着きました。具体的には以下です。

$ rsync --delete --iconv=UTF-8-MAC,UTF-8 -ave ssh ~/data/* hack_le@server:data/

これで正常に機能するようになりました。なぜこのようなことになったのか、わかる人がいれば教えてほしいものです。バグなのか、仕様なのか…。アスタリスクをつけるつけないで挙動が変わることは理解できすが、iconvの有無で変わるのはなんとも理解し難い…。

ところで、Linuxマシンに既に移してしまったUTF-8-MAC仕様のファイル名の処理には、convmvなるソフトウェアが有用だそうです。私は知らずに手作業で直したので詳細不明ですが、もし困っている人いましたら調べてみるとよいかもしれません。

関連記事

スポンサーリンク