Re: Data corruption bug in WC, apparently due to race condition?

"Bert Huijben" <bert_at_qqmail.nl> writes:
>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.

There is no need to do such a check at commit time. We do it for 'svn status', or when 'svn commit' is figuring out which files have been modified, and we should be able to guarantee that each working file's timestamp is in good order by the time a commit is finished, so that those other commands can rely on the timestamps.

>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 be able to promise that stability, even in theory. The way to avoid the theoretical issue is to install the new working file using the timestamp of the tmp file that is being atomically moved into place -- which I think is what already happens, actually. That is, when we install the working file, we always do so by first building a tmp file somewhere and then atomically renaming it to the working file, right? That rename should be preserving the timestamp of the tmp source (at least on POSIX systems?). Try this script:

  #!/bin/sh
  rm -rf foo bar
  touch foo
  ls -l --time-style=full-iso foo
  sleep 1
  mv foo bar
  ls -l --time-style=full-iso bar

Here's the output it produces on my system:

  -rw-r--r-- 1 kfogel kfogel 0 2017-08-01 13:23:33.264610172 -0500 foo
  -rw-r--r-- 1 kfogel kfogel 0 2017-08-01 13:23:33.264610172 -0500 bar

>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...

I think it's unreasonable to expect users to know what files might be involved in a commit at any given time. The user (or bot) doing the editing might not even be the same as the user (or bot) that triggered the commit. The audience for Subversion's working copy lock is Subversion itself, not "everyone on the system". Subversion operations are aware of the lock and will honor it, but we can't expect other programs/people to do so.

Best regards,
-Karl
Received on 2017-08-01 20:29:04 CEST