Hi, On Sun, Feb 8, 2009 at 10:28 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > I somehow thought that the natural reading of the guarantee is *not* that > the tokens are unique over the lifetime of the server installation (iow, a > lock token you obtained today will never be used in the future, and it is > a token that the server never has used before), but it merely guarantees > that there are no any two outstanding locks that share the same URI, lest > one client's unlock request breaks the wrong lock. But I may be wrong here. > > ... > > What breaks and how, if we do not even use a random string but a fixed > suffix ".temp" here? I am not suggesting we actually do that, but I'd > like to see how important the uniqueness is here to better understand the > issue. Having a temporary file dually ensures 1) no repository corruption 2) no pushing simultaneously to a object file. I think an example of a racy situation would help illustrate why a unique temporary file is needed (pun not intended). Imagine if two git clients, A and B, are trying to push to the repository at the same time. Let's assume that A is our "official" implementation of http-push, while B is a rogue, forked implementation of A. B is rogue because, unlike A, it doesn't care about locks on info/refs, refs/head/<branch>, etc. -- stuff that A checks for before beginning pushing objects. But apart from that, A and B are similar in all other aspects. It so happens that they're pushing the same object, say, X, to the same repository. A starts first, and during the period of the transfer of object X, B starts too. If we had used the ".temp" as you had suggested, we would have some problems due to unexpected behaviour as a result of A's and B's simultaneous writing to the file X.temp. If we had used the token instead for the temporary file name, the chances of this occurring is lowered, but still possible. That's because we're using a token from a lock somewhat arbitrarily. For example, if A was pushing to the branch "branch_A", it would lock refs/heads/branch_A and use that lock token, and if B was pushing to "branch_B", it would use the lock token obtained from locking refs/heads/branch_B. Going back to your first point on the uniqueness of the lock token, one only needs a token that's unique for the locks currently in effect. If the server had given us a token that had been used before, but isn't used by anyone else *now*, then it's ok, since we wouldn't be overwriting anybody else's file. Thus, a token that's unique *now* is sufficient. -- Cheers, Ray Chuan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
