web-dev-qa-db-ja.com

DAVとしてマウントされたSubversionリポジトリのファイルは、書き込み後すぐにゼロになります

私はSubversionリポジトリを持っています

"SVNAutoversioning on"

これにより、通常、webDAVクライアントは、チェックアウト-編集-コミットのサイクルなしでファイルに変更を加えることができます。これは、便宜上、リポジトリの一部のサブセットで適切に機能します。この例では、ソース管理ではなく、集中バージョン管理にSubversionを使用しています。

サーバーは断続的にファイルをゼロにし、geany/geditがリロードを提供し（私が学んだことはノーノーです）、リロードされたファイルは空です。それはgtkの一時ファイルと関係があるのではないかと思いましたが、viやkateで複製できます。

Viでファイルを編集する場合、成功確認の例を次に示します。

"mnt/here/bootstrap.d/edited-file"
 110L, 4077C written

リストは、ファイルのサイズがゼロ以外であることを確認します。

> ls -la mnt/here/bootstrap.d/edited-file
-rw-r--r-- 1 me me 4.0K Jan 11 07:42 mnt/here/bootstrap.d/edited-file

ただし、数秒後、リストが変更され、ファイルのゼロ化が示されます

> ls -la mnt/here/bootstrap.d/edited-file
-rw-r--r-- 1 me me 0 Jan 11 07:42 mnt/here/bootstrap.d/edited-file/chef-client

Svnリポジトリログには、おそらく責任があると思われるいくつかのトランザクションが表示されます。

==> svn.limepepper.co.uk-error.log <==
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' MOVE projects:/some/path/in/repo/this-file-gets-zeroed projects:/some/path/in/repo/this-file-gets-zeroed~
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' MOVE projects:/some/path/in/repo/this-file-gets-zeroed~ projects:/some/path/in/repo/this-file-gets-zeroed~
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' GET projects:/some/path/in/repo
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' GET projects:/some/path/in/repo
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' GET projects:/some/path/in/repo
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' HEAD projects:/some/path/in/repo/this-file-gets-zeroed~
[Wed Jan 11 01:47:07 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' LOCK projects:/some/path/in/repo/this-file-gets-zeroed

==> svn_logfile <==
[11/Jan/2012:01:47:07 -0600] service lock (/some/path/in/repo/this-file-gets-zeroed)

==> svn.limepepper.co.uk-error.log <==
[Wed Jan 11 01:47:07 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' DELETE projects:/some/path/in/repo/this-file-gets-zeroed~
[Wed Jan 11 01:47:07 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' GET projects:/some/path/in/repo
[Wed Jan 11 01:47:19 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' PUT projects:/some/path/in/repo/this-file-gets-zeroed
[Wed Jan 11 01:47:20 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' UNLOCK projects:/some/path/in/repo/this-file-gets-zeroed

==> svn_logfile <==
[11/Jan/2012:01:47:20 -0600] service unlock (/some/path/in/repo/this-file-gets-zeroed)

Svn repoDAVは次のようにマウントされます。

http://myserver/pathtorepo on /home/me/mnt/mountedhere type Fuse (rw,nosuid,nodev,noexec,relatime,user_id=500,group_id=500,allow_other,max_read=16384)




The server details are;
# rpm -qa | egrep "httpd|mod_|Subversion|dav|neon"
httpd-tools-2.2.17-1.fc14.i686
httpd-2.2.17-1.fc14.i686
mod_auth_mysql-3.0.0-12.fc14.i686
mod_Perl-2.0.4-11.fc14.i686
mod_python-3.3.1-14.fc14.i686
httpd-manual-2.2.17-1.fc14.noarch
Subversion-libs-1.6.17-1.fc14.i686
Subversion-1.6.17-1.fc14.i686
mod_dav_svn-1.6.17-1.fc14.i686
neon-0.29.5-1.fc14.i686
mod_ssl-2.2.17-1.fc14.i686

マウントされたDAVは非常に信頼性が低いと思われるため、使用を中止することにしましたが、以前あちこちで使用していた問題を解決することに興味があります。

svnwebdavdavfs2
3
Tom H

Tcpdumpを使用してトラフィックをダンプし、davfs2クライアントとSubversionリポジトリ間のプロトコル交換を調べました。

クライアントがロックを解放した時点でローカルファイルがゼロになっているように見えました。基本的にサーバーはロックの解放を確認しましたが、そのようなヘッダーが含まれていました。

Content-length: 0

応答で、dav2クライアントがローカルファイルをゼロにするように見えました。

ここの設定ファイルで次のディレクティブを使用してクライアントのロックを無効にする/etc/davfs2/davfs2.conf;

 use_locks       0

ゼロ化動作が停止しましたが、これがクライアントまたはサーバーのバグであるかどうかを確認するために、さらに調査する価値があります。

2
Tom H