You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Tom <to...@limepepper.co.uk> on 2012/01/11 09:17:12 UTC
files from subversion repo mounted as webDAV, get zeroed out shortly
after writing
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
Re: files from subversion repo mounted as webDAV, get zeroed out shortly after writing
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 11, 2012, at 02:17, Tom wrote:
> 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.
[snip]
Well something zeroes the files. I don't think it's the server.
When this happens, is the last good version of the file, before it was zeroed, still in the repository history? I mean: if the file contains "A" and you save it and all is well (file contains "A" in the repository), and then you change the file contents to "B" and save again and then notice the file has been zeroed, does the file in the repository contain "B" or still "A"?
Different editors probably employ different methods of saving files. Some might write a temporary file, then move it on top of the old file. Some might just zero the original file, then write the new one. Perhaps you would see different behavior (perhaps no failure) if you used a different editor.
Re: files from subversion repo mounted as webDAV, get zeroed out
shortly after writing
Posted by Les Mikesell <le...@gmail.com>.
On Wed, Jan 11, 2012 at 2:17 AM, Tom <to...@limepepper.co.uk> wrote:
>
> 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.
I can't help with what is going wrong, but vi will do your edit in a
tmp file copy, then truncate and overwrite your original file so as to
keep the original owner/modes which you might not be able to
reproduce. So the truncate is normal but it should be followed by
writing new contents.
--
Les Mikesell
lesmikesell@gmail.com