On Fri, Aug 10, 2012 at 7:13 AM, Junio C Hamano [off-list ref] wrote:
By the way, you can only detect such inconsistency when you are
lucky enough that you catch the other person in the middle of
writing.
If the index you are looking at holds a large tree with very many
paths, it is possible that there are two large directories, and
after you read all entries from one, the other process starts
modifying the paths in that directory, without you ever finding it
out. If the goal of the topic is to make the index work better in
projects with large trees, it may be wise to think about locking the
whole thing, so that you do not have to rely on the per-entry crc
and you being lucky to detect such a race. The per-entry crc, as
far as I understand, may have been introduced primarily to detect
on-disk data corruption; it is not a suitable mechanism to detect
conflicting accesses.
So we acquire the lock just before we need to write, or at the time we
open for reading?
--
Duy