Re: Subversion checkout issue with certain short names on Windows

On 29.03.2015 17:50, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Stephen White [mailto:swhite_at_corefiling.com]
>> Sent: vrijdag 27 maart 2015 14:03
>> To: dev_at_subversion.apache.org
>> Subject: Subversion checkout issue with certain short names on Windows
>>
>> If you pass a Windows short-name as the destination to "svn co" then it
>> will normally work correctly, unless the short name is actually longer
>> than the "long name" in which case the string handling seems to go awry.
>>
>> First a working example:
>>
>> > mkdir ALongName.impl
>> > dir /x
>> ...
>> 27/03/2015 12:50 <DIR> ALONGN~1.IMP ALongName.impl
>> ...
>> >svn co --depth=files http://svn.apache.org/repos/asf/subversion/trunk
>> ALONGN~1.IMP
>> A ALongName.impl\NOTICE
>> A ALongName.impl\get-deps.sh
>> A ALongName.impl\Makefile.in
>> A ALongName.impl\LICENSE
>> A ALongName.impl\build.conf
>> A ALongName.impl\win-tests.py
>> A ALongName.impl\COMMITTERS
>> A ALongName.impl\README
>> A ALongName.impl\BUGS
>> A ALongName.impl\configure.ac
>> A ALongName.impl\TODO
>> A ALongName.impl\.ycm_extra_conf.py
>> A ALongName.impl\INSTALL
>> A ALongName.impl\CHANGES
>> A ALongName.impl\autogen.sh
>> A ALongName.impl\gen-make.py
>> A ALongName.impl\aclocal.m4
>> U ALongName.impl
>> Checked out revision 1669571.
>>
>>
>> That's behaving as expected. SVN checks out into the ALongName.impl
>> directory, as both the long name and the short name should be
>> synonymous. It outputs the long name, not the short name given on the
>> command-line, which was slightly surprising but not a problem.
>> Presumably the result of some canonicalisation code somewhere.
>>
>> Now lets try the same sequence of operations with a different directory
>> name:
>>
>> > mkdir api.impl
>> > dir /x
>> ...
>> 27/03/2015 12:52 <DIR> API~1.IMP api.impl
>> ...
>> >svn co --depth=files http://svn.apache.org/repos/asf/subversion/trunk
>> API~1.IMP
>> A api.implP\NOTICE
>> A api.implP\get-deps.sh
>> A api.implP\Makefile.in
>> A api.implP\LICENSE
>> A api.implP\build.conf
>> A api.implP\win-tests.py
>> A api.implP\COMMITTERS
>> A api.implP\README
>> A api.implP\BUGS
>> A api.implP\configure.ac
>> A api.implP\TODO
>> A api.implP\.ycm_extra_conf.py
>> A api.implP\INSTALL
>> A api.implP\CHANGES
>> A api.implP\autogen.sh
>> A api.implP\gen-make.py
>> A api.implP\aclocal.m4
>> U api.implP
>> Checked out revision 1669571.
>>
>>
>> Here the behaviour is incorrect, it's created a new folder "api.implP"
>> and checkout out to that. The spurious "P" character is the last
>> character of the short name, so it looks like a buffer is being
>> overwritten incorrectly in situations where the long name turns out to
>> be shorter than the short name. That happens in this case because,
>> although "api.impl" is short, the "file extension" is more than 3
>> characters so this isn't a valid Windows 8.3 (short) name.
>>
>> The use of the --depth=files option isn't signficant here, it just makes
>> the reproduction steps quicker to run.
>>
>> I think this is a pretty clear example of a bug, does anyone else agree?
>
> It looks like a bug, but not one that we can fix in Subversion. We use the apr library for all our path calculations. I'm guessing that this problem occurs in the APR truename implementation, as after that the code to convert back from absolute paths back to shortnames would be affected
>
> What do you see if you just type 'svn info API~1.IMP' for that directory. (I don't think this is in any way specific to checkout)
>
>
> The obvious workaround is of course to just use the full name instead of the short name.
>
>
> Interesting followup questions would be what version of Subversion and what version of apr you are using. Perhaps this issue was already fixed.

 From what I can see just by looking at the code, the problem is that
the paths passed on the command line are used almost as-is, with only
canonicalization done on them. Those paths are used then in some parts
of the code, but once those paths are passed to the apr file-io
functions, those paths are (inside apr) translated to the long form.
Callbacks then use those long paths, but the rest of the code still uses
the short paths, and in this case they're not identical and that leads
to the described problem.
I'm pretty sure that there are other problems because of this.

I had to fix this in TSVN by making sure that all paths passed to it
(either on the command line or by entering them anywhere in the UI) are
first converted to the long format before I pass them on to the svn APIs.

A possible fix would be to do that in the svn command line client as
well, maybe in svn_opt__arg_canonicalize_path(). But this would require
ifdef statements and windows specific code, which I'm aware is not
something that the svn devs really like.
The calculated paths in svn_opt__arg_canonicalize_path would have to be
passed through the windows API GetLongPathName():
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364980%28v=vs.85%29.aspx

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net