Ping! I just noticed this thread had gone quiet. Anybody want to add
anything to the discussion, or file an issue or write a test for it?
- Julian
On 30 March 2015 at 19:32, Stefan Kueng <tortoisesvn_at_gmail.com> wrote:
> 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
Received on 2015-04-30 09:21:40 CEST