Git + Dropbox使用時の注意点

OctopressのファイルはDropboxに入れて管理していて、複数の端末からアップデートすることがあります。

先日rake deployしてもページがアップデートされないな、と思っていたらgitでcommit/pushするときにエラーが出ていました。 (generateした時のエラーは気をつけますがdeploy時はちゃんと見てなかった。。。) ついでにcygwin上でのパーミッション等についても調べたのでまとめておきます。

Dropboxでの競合エラー
Dropboxでのファイルパーミッションの問題(各OSでのパーミッションについて)
Dropbox上でのgit/svn

Dropboxでの競合エラー

ちゃんと見れば簡単なことなのですが、次の様なエラーが起っていました。

# copying public to _deploy
$ rake deploy
...

cp -r public/. _deploy
cd _deploy

# Commiting: Site updated at 2013-05-11 16:59:45 UTC
fatal: Reference has invalid format: 'refs/heads/master (XXXX の競合コピ ー 2013-05-10)'

# Pushing generated _deploy website
fatal: Reference has invalid format: 'refs/heads/master (XXXX の競合コピ ー 2013-05-10)'

# Github Pages deploy complete
cd -
fatal: The remote end hung up unexpectedly

よく見ればちゃんとfatalと言ってるんですが、ローカルでpreviewチェックはOKだったのでdeployコマンド打ってブラウザでチェック、まではもう深く考えない流れ作業なので、ブラウザを何度更新してもアップデートされないな、とちょっと悩んでしまいました…

問題は_deploy/.git/refs/heads/以下に上に出ている master (XXXX の競合コピー 2013-05-10)と言う名前のファイルが出来ていて、 gitが変なファイルがあって分からない、と言っている訳です。

このファイルは、Dropboxで競合が起こった時に上手くマージ出来なかった時に作られます。今回は片方の端末でDropboxがちょっと落ちていた時があって、その間にもOctopress内をアップデートしてしまったのが原因だと思います。

取り敢えず、このmaster以外にもいくつか競合コピーがあったので全て削除したら文句を言われなくなりましたのでOKです。

Dropbox内なので、最悪上手くいかなくても復元出来るので取り敢えず消してしまいましたが、安全を取るならバックアップを取っておくべきかもしれません (この程度のことならば冗長かもしれませんが)。

Dropboxでのファイルパーミッションの問題(各OSでのパーミッションについて)

ついでに、これまで何度かファイルのパーミッションがおかしくて手で権限変更したりする必要があって気になっていたことがあったので調べてみました。

通常、Dropbox内でのファイルをExploerとかから見る場合は読み取り実行など問題ありません。

ただ、Macでターミナルから見たり、Windowsでcygwinからファイルを見たりするとそれぞれのパーミッションが違って見えます。

最初はMacとWindows(cygwin) で使っているとそれぞれでパーミッションの構造自体が単に違うだけかな、とか思っていたんですが、どうやらDropboxでは基本的にファイルやディレクトリのパーミッションは伝播されず、1つの端末でパーミッションを変更しても他の端末では反映されません。(Windows同士でも反映されませんでした。)

さらに、問題はファイルなどが作られた時の初期パーミッションが環境によって違うことです。

通常の設定だと、ファイルやディレクトリ(フォルダ)を作った場合次の様なパーミッション(権限) ¹ になります。

OS	作成方法	作成物	権限
Windows²	Explorer	ファイル	700(*)
	Explorer	ディレクトリ	700(*)
	Command	ファイル	644
	Command	ディレクトリ	755
Mac³	Finder	ファイル	644
	Finder	ディレクトリ	755
	Command	ファイル	644
	Command	ディレクトリ	755
Linux⁴	Macと同じ

Explorer、FinderとなっているのはExplorer等で右クリックから新規作成で作った場合です。 OSの普通の作業で作られる場合も同様で、従ってDropboxの同期によって作られるファイルもExploerと同様になります。

見て分かるように、Macの場合はFinderでもコマンドラインからでも同じ様に扱われますが、 Windowsの場合、cygwin以外で作られたファイル等は全て 700のパーミッションを持っています。

追記: 2013/06/25

WindowsのAdministrators状態について

さらに700と言っても

$ ls -l
-rwx------+ 1 Administrators None 2 May 12 21:00 a.txt

の様に所有者を見るとAdministratorsになっています。 cygwin上で作ったファイルはちゃんとユーザーのものになります。

$ touch b.txt
$ ls -l
-rwx------+ 1 Administrators None 2 May 12 21:00 a.txt
-rwx------+ 1 User           None 2 May 12 21:10 b.txt

この所有者はExploerからファイルを右クリックしてプロパティの詳細から見れるものとは同期してない様です。新規作成で作ったテキスト等は詳細ではユーザー名になっていても cygwinからはAdministratorsの物に見えていました。

Windows内のDropbox以外のフォルダも見てみましたが、最初にシステムに作られるユーザーのもの(Desktopフォルダだったり)はユーザーの所有に見えたり、その後自分で作った物に関しては作ったソフトも関係しているのか、まばらでいまいちどの様に決まるのか良く分かってません。

問題なのはAdministrators用で700なので、ここでユーザーに権限が無いように見えることです。これに関しては詳しく調べて無いですが、手元で使ってる環境で、共にユーザーが管理者権限持っていてUAC等切っている状態で、

Windows Vista : 読む、実行はできるが書き込みが出来ない。ただ、どうも 管理者だけど書き込み権限が無い状態にあるみたいで、viで:w!とすれば書き込めるし、 chmod +w a.txtとすれば普通に書き込める様になる。(ls -lの結果は変わらず)。所謂root権限状態?
Windows 7: Administrators所有で700になっているファイルも普通に書き込める。つまりAdministratorsと管理者権限を持ったユーザーの区別無し?

といった感じです。問題なのはVistaの場合で、 DropboxでOctopressの記事なんかを管理していると全てreadonlyの状態になっているので他で作った記事は毎回chmod +w fileする必要があります。 rake isolate[file]的な事を一旦すれば、全てが再生成される形になるので、記事全てがreadonly状態に。

仕方が無いのでoctopressのトップディレクトリやDropboxのトップディレクトリで気が向いたら(気になったら)

$ chmod -R +w ./

として書き込み権限を与えています。

追記ここまで

追記: 2013/06/26

ファイルを作る際に親フォルダの権限を変えると中に作られるファイルの権限も変わってくる様です。

Cygwin外で作られるファイルがAdministratorsの所有物なのは変わらないのですが、フォルダをchmod 755 folderとしてからfolder内に Cygwin外からファイルを作ると、パーミッションが755だったりします。さらにファイルに書き込み可能だったりします。また、フォルダをchown +w folder等としても同様(?)。

取り敢えず、Cygwinでのトップディレクトリに行って全部USER所有に変えてみました。

$ cd /
$ chown -R +w ./

この状態で、Explorer上で新規ファイルを作ったりするとAdministrators所有で 700状態ですが、USERで書き込み可能です。

この状態でDropboxで新たなファイルを他のPCで追加した所、同期されたファイルは

$ ls 
----------+ 1 Administrators None     0 Jun 26 23:00 a.txt

の様な形に…読んだりパーミッションを変えたり所有者を変えたりはできますが、最初の状態は書き込み不可なので結局以前と一緒です。

ソフトによっても動作が違う様で、イマイチ良くわからない、という感じで中途半端で申し訳ないですが、取り敢えず、Cygwinからよく使うフォルダはchmod -R +wしておくと Explorerなどで作ったファイルは書き込み可能な状態に出来ます。

ただ、VistaでDropboxフォルダを使う場合、Dropbox経由でコピーされてきたファイルはどうしても書き込み権限が無い状態で作られるようです。 (cronでchmod -R +w ./Dropbox的なコマンドを1日1回くらい実行する、とかで対処するくらいしかないのでしょうか…?)

追記ここまで

WindowsではNTFSアクセス制御リスト(Access Control List, ACL) ⁵ ⁶ と呼ばれるシステムでファイルを管理していて、これで決定されたパーミッションがcygwinからも見えています。つまり、通常作られるファイルは、他人からは見えない様なファイルで、所有者には実行権限も与えられています。

このACLは/etc/fstabへマウント設定を追加してあげると無効にすることが出来ます。 ⁷

以下に設定変更方法を書いていますが、下にも書く様に副作用が強いため、結果的には使わないことにしています。

まず、現状のマウントポイントを確認:

$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)

/etc/fstabに何も書かれて居ない状態ですが、上の4つについては最初からマウントされるようになっています。のでセットアップで特に変更しなければ上の様になっているかと思います。

次に、これらに関連する項目を/etc/fstabへ書いて定義を変更します。

/etc/fstab

C:/cygwin/bin /usr/bin  ntfs     binary,noacl,notexec              0 0
C:/cygwin/lib /usr/lib  ntfs     binary,noacl,notexec              0 0
C:/cygwin     /         ntfs     binary,noacl,notexec,override     0 0
none          /cygdrive cygdrive binary,noacl,notexec,posix=0,user 0 0

と追加します。(初期のままだと/etc/fstabにはコメントが書かれているだけです。)

書き方は ⁸

Windowsのパス Cygwinのパス ファイルシステム　オプション 0 0

Windowsのパスも\でなく/を使います。最後のcygdriveの設定ではファイルシステムはcygdriveを設定します。最後の2つはdump/fsckオプションですが、cygwinでは使わない(?)ので、ここでは0にしておきます。

上で確認したものと比べて分かるように、追加したオプションは noaclでこれによってACLの設定を無視する様になります。

この設定を加えてからcygwinを再起動すると、全てのファイルの cygwinから見えるパーミッションが変わります。

ただ、noaclだとファイルのパーミッションをcygwinが勝手に中身を判断して決定するようになってしまい、chmod等でも変更が出来ません ⁹。

さらに気持ち悪いことに、実行権限が無いファイルでも実行出来てしまうようになります。 (TAB補完は効かないが、ちゃんと書けばどんなファイルでも実行しようとする。)

また、exec/notexecと言うオプションがあって、これらを指定すると以下のディレクトリのファイル全てが実行ファイル(755)/通常ファイル(644) になります。この場合でも一意に決まってしまって変更出来ません。

ので、結局上の設定を消して元に戻しました。 (元に戻すと、noacl等を設定する以前のパーミッションに全て戻ります。)

大分古い記事ですがACLやマウント方法について詳細に書いてあるものもありました ¹⁰。細かい事を直したいときに参考になるかもしれません。

Dropbox上でのgit/svn

パーミッション関連で困ることは、勿論スクリプトに実行権限がついてなくて実行出来ない、と言うこともあるのですが、それ以上にgitでコミットするといちいちファイルモードを変更してしまって困ってしまいます。

なので、特にDropbox上でgit(svnでも)のレポジトリを管理している場合は、

git config core.filemode false

するか./.git/configを書き換えて(filemode = trueをfalseへ) ファイルのパーミッションは無視する様にした方が余計な変更を入れないので良いと思います。

特にOctopressの様な場合は、基本的に実行ファイルは含まないので、問題ないと思います。

Octopressの場合はOctopressの親ディレクトリの./.git/configと deploy用の./_deploy/.git/configを変更して下さい。

ちなみに、大概の場合各レポジトリのconfigファイルにfilemodeの設定が加えられているので $HOME/.gitconfigで設定しても意味がないことが多いので注意が必要です。