[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[Client developers HEADS-UP] Penalty of APR_FILEPATH_TRUENAME (Was RE: svn commit: r35733 - trunk/subversion/bindings/javahl/native)

From: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Sat, 7 Feb 2009 14:36:12 +0100

> Log:
> * subversion/bindings/javahl/native/JNIUtil.cpp
> (JNIUtil::preprocessPath): Remove a gigantic Windows only performance
> penalty by using the always correct svn_path_internal_style()
> instead
> of the hidden breaking apr_filepath_merge with
> APR_FILEPATH_TRUENAME
> that only did validation on Windows.

        Hi,

Until recently some parts of Subversion used apr_filepath_merge with the
APR_FILEPATH_TRUENAME flag all over the place. (It currently only uses it
for paths passed to svn via the commandline where it is actually usefull for
catching user typos).

Using this method is VERY VERY expensive on Windows. Our (and your) code
should canonicalize paths only once. Exactly when passed from an untrusted
source and after that assume that paths are canonical (or at least correctly
cased).

(Apr ignores this flag on all OSs except Windows, so as Linux developer you
would never know.)

I would recommend that other subversion client developers review their code
to make sure they don't accidentally call this same method without realizing
that this is expensive and you can get a fILE back when you gave the method
a File.

In 99.9% of all cases this normalization does nothing, except for costing a
lot of time; in that other 0.1 percent (where the file on disk has another
casing than subversion thinks it has), it makes it impossible for you to
call subversion commands on the administratively managed file, as it would
automatically 'repair' your 'File' to 'fILE'.

Thanks for your attention,

        Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1119074
Received on 2009-02-07 14:36:32 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.