Tay Ray Chuan <rctay89@xxxxxxxxx> writes: > In section 6.5 which you cite below, the token is unique, and we hold > the server's word for it. Are you sure you are not reading too much into that guarantee? 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. >> 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. Let me show even more ignorance of mine with this codepath. 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. -- 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
