Файлы из репозитория Subversion смонтированы как DAV, обнуляются вскоре после записи

У меня есть репозиторий Subversion с

"SVNAutoversioning on" 

который обычно позволяет клиентам webDAV вносить изменения в файлы без цикла checkout-edit-commit, и для удобства это работает хорошо для некоторого подмножества хранилища. В этом случае я использую 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 репо DAV монтируется как;

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, поскольку он выглядит ужасно ненадежным, но мне было бы интересно решить эту проблему, так как я использовал ее здесь и там ранее.

1 ответ

Решение

Я выгрузил трафик с помощью tcpdump и проверил обмен протоколами между клиентом davfs2 и хранилищем subversion.

Локальный файл, по-видимому, обнулялся в тот момент, когда клиент снял блокировку, в основном сервер подтвердил снятие блокировки, но включил такой заголовок;

Content-length: 0

в ответе, который, по-видимому, заставляет клиента dav2 обнулять локальный файл.

отключение блокировок на клиенте с помощью следующей директивы в файле конфигурации здесь /etc/davfs2/davfs2.conf;

 use_locks       0

вызвал остановку поведения обнуления, но было бы целесообразно провести дальнейшее расследование, чтобы выяснить, является ли это ошибкой на клиенте или на сервере.

Другие вопросы по тегам