[jira] [Updated] (SVN-4708) WC can't detect local mods after modify working file during commit.

["Karl Fogel (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SVN-4708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karl Fogel updated SVN-4708:
----------------------------
    Summary: WC can't detect local mods after modify working file during commit.  (was: WC can't detect local mods due if modify working file during commit.)

> WC can't detect local mods after modify working file during commit.
> -------------------------------------------------------------------
>
>                 Key: SVN-4708
>                 URL: https://issues.apache.org/jira/browse/SVN-4708
>             Project: Subversion
>          Issue Type: Bug
>          Components: libsvn_wc
>    Affects Versions: 1.9.6, 1.9.7, 1.10.0-alpha3
>            Reporter: Karl Fogel
>
> Saving changes to a working file during a commit process that includes that file can leave the WC in a slightly corrupted state: the working file may be out-of-date w.r.t. what's committed and in the repository, and yet "svn status" locally claims there is no modification.
> See discussion "Data corruption bug in WC, apparently due to race condition?" on SVN Dev mailing list, starting with this message (plus a slight clarification in an immediate followup post from the same author):
> {quote}  
>   From: Karl Fogel
>   To: Subversion Dev
>   Subject: Data corruption bug in WC, apparently due to race condition?
>   Date: Thu, 27 Jul 2017 01:21:54 -0500
>   Message-ID: <87...@floss>{quote}
> at this message link:
> [http://mail-archives.apache.org/mod_mbox/subversion-dev/201707.mbox/%3C871sp2tn5p.fsf%40floss%3E]
> Philip Martin confirmed and found a reliable reproduction recipe:
> {quote}
>   From: Philip Martin
>   To: Karl Fogel
>   Cc: Subversion Dev
>   Subject: Re: Data corruption bug in WC, apparently due to race condition?
>   Date: Thu, 27 Jul 2017 18:56:37 +0100
>   Message-ID: <87...@codematters.co.uk>{quote}
> in
> [http://mail-archives.apache.org/mod_mbox/subversion-dev/201707.mbox/%3C87zibpn4q2.fsf%40codematters.co.uk%3E]
> I will just copy Philip's reproduction recipe here:
> {quote}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.
> In first terminal:
>   $ svnadmin create repo
>   $ svnmucc -mm put <(echo foo) file://`pwd`/repo/f
>   $ svn co file://`pwd`/repo wc
>   $ echo bar > wc/f
>   $ gdb --arg svn ci -mm wc
>   (gdb) b svn_client__do_commit
>   (gdb) r
>   hit breakpoint
>   (gdb) fin
>   run to end of svn_client__do_commit
> Switch to second terminal:
>   $ svn st wc
>     L     wc
>   M       wc/f
>   $ cat wc/.svn/pristine/*/*
>   foo
>   bar
>   $ echo zigzag > wc/f
> Switch back to first terminal:
>   (gdb) c
>   (gdb) q
>   $
> I believe that reproduces the problem:
>   $ svn cat -r1 wc/f
>   foo
>   $ svn cat -r2 wc/f
>   bar
>   $ cat wc/f
>   zigzag
>   $ sqlite3 wc/.svn/wc.db "select translated_size from nodes where local_relpath='f'"
>   7
>   $ svn st wc
>   $
>   $ touch wc/f   # to break timestamp
>   $ svn st wc
>   M      wc/f
> To fix this we would need to have the client's post-commit processing do
> a full-text comparison to catch modifications before storing the
> timestamp/size in .svn/wc.db.  Avoid a race is a bit tricky, perhaps:
>   1) stat() to get timestamp/filesize
>   2) full-text compare to ensure text is unchanged
>   3) stat() to ensure timestamp/filesize is unchanged
>   4) store timestamp/filesize{quote}
> There's some more followup discussion in the thread (note: crossing a month boundary into August, so you may need to do some manual stepping to find all of the discussion).  The consensus of the thread is, if I understand it correctly, that this is real bug and it is 100% fixable -- that is, it's not a matter of shrinking the window for the race condition, but of getting rid of it altogether.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)