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.
