Home / server / Questions / 348751
Accepted
Tom
Asked: 2012-01-11 23:57:34 +0800 CST

files from subversion repo mounted as DAV, get zeroed out shortly after writing

  • 772

I have a subversion repo with 

"SVNAutoversioning on"

which usually allows webDAV clients to make changes to files without a checkout-edit-commit cycle, and this works well for some subset of the repository for convenience. In this instance I am using subversion for centralized versioning rather than source control.

The server intermittently zeroes out the files, either geany/gedit offers a reload (which I have learned is a no-no) and the file reloaded is empty. I thought it might be something to do with gtk temp files, but it is replicable with vi or kate.

If I edit a file in vi, here is the example of the success confirmation;

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

and listing confirms that the file has non-zero size;

> 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

however a couple of seconds later the listing is changed showing the zeroing of the 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

The svn repo log shows a couple of transactions that are presumably responsible.

==> 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)

The svn repo DAV is mounted as;

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

I've decided to sack off using the mounted DAV as it appears to be terribly unreliable, but I would be interested in solving the problem as its something I have used here and there previously.

svn webdav davfs2

1 Answers

  1. Best Answer

    I dumped out the traffic using tcpdump, and examined the protocol exchange between the davfs2 client and the subversion repository.

    The local file appeared to get zeroed out at the point the client released the lock, basically the server acknowledged the lock release, but included a header like so; 

    Content-length: 0

    in the reply, which appeared to cause the dav2 client to zero out the local file.

    disabling locks on the client using the following directive in the config file here /etc/davfs2/davfs2.conf;

     use_locks       0

    caused the zero-ing out behaviour to stop, but it would be worth further investigation to discover whether this is a bug in the client or the server.

    • 2