[bug report] command-line svn.exe with short-name argument does not work when short-name is longer than long-name

14 views
Skip to first unread message

Hans-Jakob Holtz

unread,
Nov 27, 2017, 8:17:18 AM11/27/17
to TortoiseSVN
Hi there,

in order to avoid problems related to unicode and windows command-line, I'm calling C::\Program Files\TortoiseSVN\bin\svn.exe with the (dos-compatible 8.3) short-names of my files.
This works beautifully in most cases. I even get the correct long-name in the --xml output.

However, when the short-name is longer than the long-name, svn.exe consistently reports the status for the wrong file (which in most cases does not exist):

Suppose I have a file "a.txt" with short-name "abcdefg.txt":

# copy nul a.txt
# fsutil file setshortname a.txt abcdefg.txt
# dir /x
(...)
27.11.2017  14:04                 0 ABCDEFG.TXT  a.txt
(...)

# svn status a.txt
?       a.txt

# svn status --xml a.txt
<?xml version="1.0" encoding="UTF-8"?>
<status>
<target
   path="a.txt">
<entry
   path="a.txt">
<wc-status
   item="unversioned"
   props="none">
</wc-status>
</entry>
</target>
</status>

# svn status ABCDEFG.TXT
(no output at all)

# svn status --xml ABCDEFG.TXT
<?xml version="1.0" encoding="UTF-8"?>
<status>
<target
   path="a.txtFG.TXT">
</target>
</status>


When watching svn.exe with SysInternals ProcessMonitor, accesses to a.txtFG.TXT are also visible.

This last output and ProcessMonitor result makes me believe this might be some kind of string termination issue.

In my original use case, the "overly long" short-name is auto-generated by windows for a single-character non-latin (e.g. cyrillic or chinese) long-name.

The issue occurs with svn.exe provided by TortoiseSVN 1.9.7 Build 27907. I have not tried earlier versions.
The svn.exe copies provided by Slik Subversion 1.9.7 and 1.9.5 do not exhibit this behaviour, which is why I'm specifically reporting this to TortoiseSVN.

Best regards
Hans-Jakob Holtz

Stefan

unread,
Nov 28, 2017, 11:06:34 AM11/28/17
to TortoiseSVN
That's an issue with the command line client, not TSVN.
You have to report this on the svn users list:
http://subversion.apache.org/mailing-lists.html
Reply all
Reply to author
Forward
0 new messages