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

From: Tay Ray Chuan <rctay89@gmail.com>
Date: Feb 8, 2009, 01:45 UTC
Message-ID: <be6fef0d0902071745r355309c2o76622b3af8df53bc@mail.gmail.com>
In-Reply-To: <7v1vuavv4l.fsf@gitster.siamese.dyndns.org>

Hi,

On Sun, Feb 8, 2009 at 4:40 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 13 quoted lines

> 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