Re: [PATCH] use lock token in non-URI form in start_put

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Sun, 8 Feb 2009, Tay Ray Chuan wrote:
>
>> After 753bc91 ("Remove the requirement opaquelocktoken uri scheme"),
>> lock tokens are in the URI forms in which they are received from the
>> server, eg. 'opaquelocktoken:', 'uuid:'
>>
>> However, "start_put" (and consequently "start_move"), which attempts to
>> create a unique temporary file using the UUID of the lock token,
>> inadvertently uses the lock token in its URI form. These file
>> operations on the server may not be successful (specifically, in
>> Windows), due to the colon ':' character from the URI form of the lock
>> token in the file path.
>
> If it is a prefix that happens to be part of the URI, but must not be used 
> by the client code as a lock token, would it not be better to store the 
> token in lock->token to begin with?

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.

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.

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.