I have a subversion repo exposed through mod_dav_svn and the option "SVNAutoversioning on" and am using fusefs with davfs2 to mount the repo on my linux desktop fedora 15.

This 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



Any suggestions on what might be the problem. (I dont see this setup as a long term development environment, but it is convenient -except when it trashes the config files ... )

Thanks
Tom

Reply via email to