WSL と Windows のファイル同期に Syncthing を使ってみた

と言う話。

ちなみに、Syncthing とはこれ:


僕は開発中のソースコードの類いを、 BitLocker で暗号化した vhdx コンテナ に保存していて、 普段、開発するときは、そのコンテナをマウントして、 BitLocker でのロックを解除した状態で色々開発をしています。

でまあ、なんで仮想ディスクをファイルコンテナとして使ってるかって言えば、 * Dropbox で生のソースコードを同期すると、Git リポジトリとかあるいは node.js のモジュールとかが競合した時に、 競合の解除が非常に面倒だし、あと下手すると Git リポジトリがぶっ壊れたりするためで、 これで昔大変に面倒な思いをした事が有るからです。

それでまあ Dropbox でソースコードとか同期する時は、 * Windows だと vhdx だとか、あるいは macOS だと sparsebundle とか使ってたんですが、 ここ最近、 開発環境を MSYS2 から Archlinux on WSL に移してた時に、

うーん、ファイルの同期というか、ソースコードとか dotfiles の共有はどうしよう

ってなった訳です。

まあ MSYS2 だと、中身というかファイルやディレクトリは Windows のそのままが使えるんで、 特に悩む事なく vhdx をマウントして symlink 貼って、って出来たんですが、 * Windows Subsystem for Linux の Distro (僕の場合 Archlinux) だと、

WSL のファイルを Windows 側から触ると、WSL 側からファイルが見えなくなる等で壊れる

と言う問題が、今現在 (2017-01-31) の時点では有る訳で、その辺りどうしようかなーと思ってた時に、ふと、

あ、これ Syncthing を使えばなんとかなるんじゃね?

って思いついて、とりあえず今、それでファイルを同期しています。


それで、今は Syncthing で WSL と Windows でファイル同期しているんですが、 これを安定して動かすには幾つか注意点が有ります。

と言うのも、

Windows + WSL で環境構築する

っていうのは、

Linux で Wine を使って環境構築する

みたいな感じに近く、Listen する port はさすがに共有されるため、 Syncthing で使う Port を、 Windows 側か WSL 側のどちらかを競合しないように変えてやらないと、 Listening Port の取り合いになって、微妙に奇妙な挙動になります。というかまともに使えない状態になります。

また、僕は WSL の Distro を Archlinux に入れ替えていて使っていますが、 WSL での Linux 環境は chroot 環境に近く、systemd 等は動いておらず、 デーモンは動かせるけど、systemd のサービスは動かしようがないため、

Synthing を systemd でサービスとして動かす

というのは出来ません。

それで、その辺り僕はどうしたかっていうと、これは、

tmux で syncthing をバックグランドプロセスとして動かす

と言う、 運用でカバー みたいな方法で解決しています。

ただし、この 運用でカバー なデーモン管理、時々 Syncthing が panic 吐いて落ちる (Syncthing は golang 製) ので、 この辺りは foreground のデーモンが落ちないように、何かしらのデーモンマネージャを使った方が良いんじゃないか、と思ってます。 ただ、僕はまだこの辺りの作業をしてなかったりしますけども。


まあ、そんな感じで僕は Synthing を使って運用していますが、 これは別に Syncthing じゃなくても、

でも出来るハズ……だと思うので、人に依ってはそっちの方が良いかもしれません。

あと、先程言い忘れてましたが、僕の環境では、 node.js のモジュールみたく、

開発ディレクトリにインストールされる環境依存のモジュール

みたいなのは、基本、同期しないようにしています。まあ当然の事なんですけど、 Windows と Linux のバイナリは相互運用出来ませんからね。そもそも実行バイナリの形式自体違うし。


ま、話としてはそんな感じです。はい。

nyarlaが大体

Scrapbox.io でコメントや意見を書く