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 <tortoise...@gmail.com> wrote: > On 29.03.2015 17:50, Bert Huijben wrote: >>> -----Original Message----- >>> From: Stephen White [mailto:swh...@corefiling.com] >>> Sent: vrijdag 27 maart 2015 14:03 >>> To: dev@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
