Hi, On Sun, Feb 8, 2009 at 4:40 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Let me show more of my ignorance around this codepath. > > What is the real purpose of this appending? My understanding is that it > is to ensure that a tentative PUT goes to a new file, so that a DAV server > whose PUT is not atomic (i.e. can leave a half-written bogosity when the > operation fails for whatever reason) won't leave a broken object in its > object store. We MOVE it to its final destination and expect that to be > atomic. This happens to be my understanding as well. > Does the server side guarantee that the lock token string is unique in the > sense that it does not reuse a token that was used for a recent > transaction that was aborted? If there is no such guarantee, then using > (a part of) the lock token as the string we append is no better than using > a random string we choose ourselves. In section 6.5 which you cite below, the token is unique, and we hold the server's word for it. > We may need to send the exact lock token back for unlocking the > transaction we started, but I do not think it necessarily is a good idea > to tie that to the random string we would use for PUT-then-MOVE operation. > > RFC 4918 (section 6.5) explicitly states that the servers are free to use > any URI so long as it meets the uniqueness requirements, so relying on it > being any form of uuid does not sound like a good idea. It can contain > not just a colon but other potentially problematic characters, such as a > slash, no? > > That is why I asked in my previous question what in the codepath protects > ourselves from using problematic characters. > You're right, section 6.5 doesn't enforce that lock tokens are UUIDs. Any solutions to this? Perhaps one could have a function, say, get_unique_remote_postfix, and the function would check for URI schemes which we know are safe for use in file names, namely, "urn:uuid:" and "opaqulocktoken:". However, if its a URI we are unsure of, then it would generate a random string. -- 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
