> -----Original Message-----
> From: Philip Martin [mailto:phi...@codematters.co.uk]
> Sent: donderdag 27 juli 2017 19:57
> To: Karl Fogel <kfo...@red-bean.com>
> Cc: Subversion Dev <dev@subversion.apache.org>
> Subject: Re: Data corruption bug in WC, apparently due to race condition?
>
> Karl Fogel <kfo...@red-bean.com> writes:
>
> > 1) Start an SVN commit.
> >
> > 2) While the commit is in progress, edit and save a
> > change to one of the files that's being committed.
> >
> > 3) The commit completes successfully, or "successfully", but...
> >
> > ...now the repository has the file contents from before my edit of
> > (2), the working copy has the file contents from *after* my edit of
> > (2), but SVN reports no local modifications when I do 'svn status'.
> > That's... bad, right? :-)
>
> The post-commit processing on the client side is not checking for
> modifications before recording filesize/timestamp in the nodes table in
> .svn/wc.db.
There used to be a system for this around the release of Subversion 1.7.0.
Not sure what happened to this...
There should be a comparison (probably via one of the wc question apis) if
the timestamp changed since what was committed.
But even then there is a theoretical issue, between the file install and
then obtaining the timestamp+size directly after that. But you shouldn't be
able to trigger that without a debugger. Unlike this case where the whole
commit is locked.
We should do better, but we don't promise that this editing while committing
is 100% stable. During the working copy lock we should have exclusive access
to the locked parts of the working copy...
Bert
