On Thu, Jul 20, 2017 at 11:01:45PM -0700, Junio C Hamano wrote: > The general strategy we take for these atomic update of a file > entity at $path is to: > > (1) try to create $path.lock exclusively; if we cannot, somebody > else holds the lock so fail (or backoff and retry, which > amounts to the same thing in the larger picture). > > (2) update $path.lock and close the fd. > > (3) rename $path.lock to $path atomically to unlock. > > Would it be sufficent to tweak the above procedure with a new, > zeroth step? > > (0) see $path is a symlink; if so, readlink it and assign the > result to $path. Then go on to step (1) above. > > I do not think such an enhancement would break atomicity guarantee > we want from the locking. When updating .git/packed-refs in an > ancient new-workdir'ed directory, we would end up locking the > corresponding file in the real repository, which is exactly what we > want anyway. As the basic assumption of having a symbolic link in > the new-workdir'ed directory is that a symlink can stay the same > forever while the linked target will be updated, I think this would > be a reasonable short-term "fix". This seems like the correct path to me. If the existing behavior is to lock the referring symref, that seems like a violation of the lock procedure in the first place. Because if "A" points to "B", we take "A.lock" and then modify "B". But "B" may have any number of "A" links pointing to it, eliminating the purpose of the lock. I thought we already did this, though. And that modifying HEAD (which might be a symlink) required LOCK_NO_DEREF. -Peff
