symfonyの開発中で、クライアントがWindowsXP(SP3)、サーバはクライアントのWindowsにインストールしたVMWareの中でFedora9を動かしている環境。Fedora9は現在最新版のsamba()をインストールしていて、WindowsからUNCパス(\\servername\hogeという指定)でプロジェクトごとe-texteditorで開いて作業している。subversionはサーバ側が1.4系列、クライアント側はTortoiseSVNの1.5系列、https/WebDAVを使っていて、サーバは手元とは別の場所にある。

このような環境下で、場合により「コミットには成功しましたが続けて他のエラーが生じました」「次のパスを処理する際にクリーンアップに失敗しました」というようなエラーがでる。だが、このエラーメッセージをgoogleで調べても、TortoiseSVNの言語ファイルのソースばかり出てきてエラーにはたどり着くことが出来ない。

そこで、その言語ファイルの訳語元「Commit succeeded, but other errors follow」や、「」を調べていて、やっとこさそれっぽい記事にたどり着いた。このMLのスレッドでは、解決策として「samba使うのを止めるか」または「最新のsambaに入れ直せ」、ということになっている。調べてみると、その記事の書かれたとき(2008/09/15)のsambaの最新版は3.2.3。その３日後に3.2.4が出ている。手元の環境は3.2.3-0.20.fc9。このドキュメントを信用する限り問題はないはず。

だが、その環境で問題が起こっているので、念には念をということで3.2.4をfedora-updates-testing-newkeyリポジトリから拾ってみた。インストールされたバージョンは3.2.4-0.21.fc9。だが、やはり問題は再現したのであった。

その後、Eclipse+PDT+Subclipse1.4.xの環境でも同じ問題が発生したこともあり、どうもTortoiseSVNが原因ではない模様。ついったでしばらく文句垂れていたのは冤罪だったようだ。ほんとごめん>TSVN

このまま調べるのをやめてしまうと、また問題が起きるたびにフォローアップ作業をしなければならない。それは悔しいのでもう少し調べてみると、こんな記事を見つけた。曰く、共有フォルダごとの設定に、create maskやらの設定を追加するとちゃんと動くようになるよ!　とのこと。うちではこんな風に書き換えてみた。下線部分が追記分。

[homes]
        comment = Home Directories
        browseable = no
        writable = yes
        create mask = 0644
        force create mode = 0600
        security mask = 0555
        force security mode = 0600

試してみると、これがなんとエラーが発生しなくなるではないか・・。

原因が良く説明できないが、症状がなくなったことは大変めでたい。もし正確な原因がわかる方がいればコメントいただければ幸い。