rcmdnk's blog
Last update

20130513_dropbox_200_200

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

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

Sponsored Links

Dropboxでの競合エラー

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 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同士でも反映されませんでした。)

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

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

OS 作成方法 作成物 権限
Windows2 Explorer ファイル 700(*)
ディレクトリ 700(*)
Command ファイル 644
ディレクトリ 755
Mac3 Finder ファイル 644
ディレクトリ 755
Command ファイル 644
ディレクトリ 755
Linux4 Macと同じ

ExplorerFinderとなっているのは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) 5 6 と呼ばれるシステムでファイルを管理していて、 これで決定されたパーミッションがcygwinからも見えています。 つまり、通常作られるファイルは、他人からは見えない様なファイルで、 所有者には実行権限も与えられています。

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

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

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

$ 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
1
2
3
4
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にはコメントが書かれているだけです。)

書き方は 8

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

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

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

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

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

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

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

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

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

Dropbox上でのgit/svn

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

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

git config core.filemode false

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

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

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

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

Sponsored Links
  1. ここではWindowsの場合はcygwinから見た場合のパーミッションの話です。 Unix系の権限は所有者、グループユーザー、その他の枠でそれぞれ、 読み(4)、書き(2)、実行(1)の権限を指定しますが、この時、 表にあるように権限の数字を足した物を並べて表示します。 ls -lするとrwxr-xr-x等と出ますがこれは所有者r(読み)w(書き)r実行可能で、 グループユーザー及びその他は読み込みと実行のみ許可されている、と言うことで、 数字では755になります。

  2. Windows Vista/7, cygwin 1.7.18

  3. Mac OS X Lion (10.7.5)

  4. Scientific Linux 6

  5. アクセス制御リストACLとは?

  6. Windowsアクセス権設定(ACL)の基礎知識

  7. Cygwin 1.5からCygwin 1.7へのアップグレード

  8. Cygwin1.7の /etc/fstabのフォーマット

  9. 先頭行を見て#!等かどうかで判断して実行ファイル(755)か 通常ファイル(644)に自動的に決まるとのことです: Ref 普段はWindowsを使っているのよ

  10. Cygwin for Professionals

Sponsored Links

« Topへ戻るボタンの設置 Firefoxの表示をすっきりカスタマイズ »