Hi Bert,
thanks for your reply. I'm inclined to agree, and I don't like the
current approach (which I didn't write ;-), also because we use a number
of other tools in our build, and may add more later, and they might also
fail to cope with long paths. I'd rather see us keep paths to <260
chars. For now I've worked around the issue by changing our custom
build tool not to use "\\?\", just on my local machine.
Regards,
Hugh Greene, Senior Software Developer
Toshiba Medical Visualization Systems Europe, Ltd
Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK
Tel + 44 (0)131 472 4792 / Fax + 44 (0) 131 472 4799
http://www.tmvse.com <http://www.tmvse.com> / mailto:hgreene@tmvse.com
<mailto:hgreene_at_tmvse.com>
DISCLAIMER
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically
authorized to receive it. If you are not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
message and/or attachments is strictly prohibited. The company accepts
no liability for any damage caused by any virus transmitted by this
email. Furthermore, the company does not warrant a proper and complete
transmission of this information, nor does it accept liability for any
delays. If you have received this message in error, please contact the
sender and delete the message.
From: Bert Huijben [mailto:bert_at_qqmail.nl] On Behalf Of Bert Huijben
Sent: 17 August 2010 14:56
To: Greene, Hugh; users_at_subversion.apache.org
Subject: RE: svn client misinterprets UNC Long Paths under Windows 7
Subversion (or actually apr) will handle the long paths internally for
you as long as you pass absolute paths, so you MUST NOT add the api long
path prefix yourself.
The prefix is only defined to work on some of the Windows apis and some
other apis just accept long paths (with explicit length) or other
methods. It might work with some programs that just open a file, but
subversion needs much more from the filesystem and therefore it must
manage the paths for itself. By passing the prefix yourself you just
assume that subversion limits itself to a fraction of the Windows API.
Bert
From: Greene, Hugh [mailto:HGreene_at_tmvse.com]
Sent: dinsdag 17 augustus 2010 5:44
To: users_at_subversion.apache.org
Subject: svn client misinterprets UNC Long Paths under Windows 7
Hi all,
I'm trying to do a checkout on a Windows 7 Professional x64 machine,
using the svn client version 1.6.6 (though I've seen the same problem
with 1.6.12, from TortoiseSVN-1.6.10.19898-x64-svn-1.6.12) against
server version 1.6.9.
The command lines I'm using are normally executed from within
CruiseControl.NET, by a custom NAnt task we've written, which launches
"svn.exe" as a process. I've used sysinternals Process Explorer to grab
the exact command line it's executing, though I've changed directory
names below to protect confidentiality.
The problem is occurring because we're using UNC Long Paths, as
described here
<http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath>,
to try to avoid maximum path length issues.
------------------------------------------------------------------------
------------------------
"svn" checkout -r HEAD http://svnserver/svn/path/to/project
"\\?\D:\src\autobuild-trunk\server\Trunk_ProjectAB\WorkingDirectory
<file:///\\%3f\D:\src\autobuild-trunk\server\Trunk_ProjectAB\WorkingDire
ctory> " --username DOMAIN\user --password ******** --no-auth-cache
------------------------------------------------------------------------
------------------------
On someone else's Windows XP SP2 x86 machine (and likewise my old
machine), this works as I'd expect, checking out the contents of
"http://svnserver/svn/path/to/project" to
"D:\src\autobuild-trunk\server\Trunk_ProjectAB\WorkingDirectory".
However, on my new machine, which runs Windows 7, the console output is
as follows.
------------------------------------------------------------------------
------------------------
U \WorkingDirectory
Fetching external item into '\WorkingDirectory\Tools'
A \WorkingDirectory\Tools\Some Build Tool.dll
A \WorkingDirectory\Tools\Tools
A \WorkingDirectory\Tools\Tools\Some Tool
[...]
------------------------------------------------------------------------
------------------------
And sure enough, it's checking out to "\WorkingDirectory", which
resolves to "D: WorkingDirectory". But if I remove the "\\?\", it
checks out to where I would expect.
Please let me know if you need any more information to investigate this.
I can work around it for now as I'm just trying to verify local
modifications to our autobuild before I check in - the autobuild machine
itself isn't running Windows 7.
Thanks,
Hugh Greene, Senior Software Developer
Toshiba Medical Visualization Systems Europe, Ltd
Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK
Tel + 44 (0)131 472 4792 / Fax + 44 (0) 131 472 4799
http://www.tmvse.com <http://www.tmvse.com> / mailto:hgreene@tmvse.com
<mailto:hgreene_at_tmvse.com>
DISCLAIMER
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically
authorized to receive it. If you are not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
message and/or attachments is strictly prohibited. The company accepts
no liability for any damage caused by any virus transmitted by this
email. Furthermore, the company does not warrant a proper and complete
transmission of this information, nor does it accept liability for any
delays. If you have received this message in error, please contact the
sender and delete the message.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
<http://www.messagelabs.com/email>
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
<http://www.messagelabs.com/email>
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
Received on 2010-08-20 17:22:33 CEST