On 10/18/2013 12:20 PM, Stefan Fuhrmann wrote:
> On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben <bert_at_qqmail.nl
> Then most likely there is a difference between implementation and
> documentation
>
> svn ls -R path
>
> will use this function with deeper names.
>
> See list.c get_dir_contents(), which calls itself recursively with
> longer and longer components.
>
> And I'm pretty sure there are also third party clients that use this
> feature via their own usage of the ra layer.
>
>
> That's what I originally thought as well. As it turns out,
> the path gets combined above the RA layer in lib_client.
>
> I spent most of today figuring out why svn ls -R left
> my laptop idle (see r1533530), so I had exactly the
> use-case that you described.
Bert, are you perhaps thinking of the *input* to svn_ra_get_dir(), which
accepts a path relative to the session URL that can have an arbitrary
number of components?
Stefan is correct that -- at least in the case of our own libraries --
the "name" parsed from the get-dir *response* should only be a single
path component. (Its source is the svn_fs_dir_entries hash keys, which
are single-component relpaths.)
That said, Stefan, we made a conscious decision to sanitize paths on
both sides of the wire because we don't control the wire itself. For
example, your libsvn_ra_svn-wielding client might not be talking to
'svnserve', but to a third-party custom implementation of the Subversion
server that speaks the 'svn' protocol. As such, there is an opportunity
for malformed data to be returned, and the canonicalization protects our
client (to a degree) from certain potentially problems there. If
anything, an additional check should be *added* at that call site to
verify that 'name' is, in fact, but a single path component.
Received on 2013-10-18 18:39:10 CEST