Re: Data corruption bug in WC, apparently due to race condition?
From: Karl Fogel <kfogel_at_red-bean.com>
Date: Tue, 01 Aug 2017 13:28:57 -0500
"Bert Huijben" <bert_at_qqmail.nl> writes:
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
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:
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
>We should do better, but we don't promise that this editing while committing
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.
This is an archived mail posted to the Subversion Dev mailing list.