apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: [Patch] apr_file_path_merge returns incorrect truepath on certain 'short paths' on Windows
Date Wed, 17 Jun 2015 03:28:29 GMT
On 15.06.2015 16:52, William A Rowe Jr wrote:
> Great report, thanks Bert.  I'll review.

I verified the patch with trunk on Windows 10/VS2015; looks good.

-- Brane


> On Mon, Jun 15, 2015 at 7:19 AM, Bert Huijben <bert@qqmail.nl
> <mailto:bert@qqmail.nl>> wrote:
>
>     Trying yet another e-mail address... Nice that this just bounces
>     instead of being moderated :(
>
>             Bert
>
>     > -----Original Message-----
>     > From: Bert Huijben [mailto:rhuijben@collab.net
>     <mailto:rhuijben@collab.net>]
>     > Sent: maandag 15 juni 2015 14:04
>     > To: dev@apr.apache.org <mailto:dev@apr.apache.org>
>     > Cc: Stephen White; dev@subversion.apache.org
>     <mailto:dev@subversion.apache.org>
>     > Subject: [Patch] apr_file_path_merge returns incorrect truepath
>     on certain
>     > 'short paths' on Windows
>     >
>     >       Hi,
>     >
>     > In the last few months we got two reports from Subversion users that
>     > passing certain short paths to 'svn' failed for them.
>     >
>     > E.g.
>     > [[
>     > > mkdir ALongName.impl
>     >  > dir /x
>     > ...
>     > 27/03/2015  12:50    <DIR>          ALONGN~1.IMP ALongName.impl
>     > ]]
>     > And then passing this 'ALONGN~1.IMP' path works just fine.
>     >
>     > While
>     > [[
>     > > mkdir api.impl
>     >  > dir /x
>     > ...
>     >   27/03/2015  12:52    <DIR>          API~1.IMP    api.impl
>     > ...
>     > ]]
>     > And then passing the 'API~1.IMP' path doesn't (uses api.implP)
>     > (Samples copied from a mail from Stephen White to
>     dev@subversion.a.o)
>     >
>     > The problem here is that the short path is actually longer than
>     the long
>     > path. which triggers a bug in APR's truename code that we use.
>     In this
>     > specific case the length of the updated path is not properly
>     updated, to
>     > reflect the shorter total path length.
>     >
>     >
>     > When trying to write a testcase for this issue I found that Windows
>     > disables short path generation on user created NTFS filesystems
>     these
>     > days. Only on system partition the default setup enables short path
>     > creation. (An admin can enable short paths via something like
>     'fsutil
>     > 8dot3name set R: 1', or a flag can be passed to format.exe)
>     >
>     > The attached patch fixes the problem, which appears to be
>     specific for the
>     > last path component (saveslash = FALSE).
>     >
>     >
>     > I would like to see this problem fixed in apr 1.5.
>     >
>     > The attached patch applies directly to 1.5.x and trunk.
>     >
>     > Thanks,
>     >       Bert
>
>


Mime
View raw message