On 17. 6. 25 09:45, Daniel Sahlberg wrote:
Den tis 17 juni 2025 kl 06:24 skrev Yasuhito FUTATSUKI
<futat...@yf.bsdclub.org>:
Hello,
On 2025/06/16 18:06, 管理员 wrote:
> If the file name ends with a space, it cannot be save to a file
then use the --targets options:
>
> For example:
>
> Files:
>
> /Users/abc/trunk/aaa
> /Users/abc/trunk/aa // ends with a space.
>
> create a file: /Users/abc/trunk/1.txt, contents:
>
> /Users/abc/trunk/aaa
> /Users/abc/trunk/aa // ends with a space.
>
> execute svn command:
>
> svn add --targets /Users/abc/trunk/1.txt
>
> svn: warning: W155010: '/Users/abc/trunk/aa' not found
> svn: E200009: Could not add all targets because some targets
don't exist
> svn: E200009: Illegal target for the requested operation
> Subversion client version: 1.14.5
> Subversion server version: 1.14.5
> OS: macOS 15.5
I could confirm the issue. With --targets option, the content
of the target file is splited by new line, and each lines are
trimed trailing white space(s).
The behaviour can be changed with following patch, but I have no
confidence that the current behaviour is intended or not.
[[[
Index: subversion/svn/svn.c
===================================================================
--- subversion/svn/svn.c (revision 1926152)
+++ subversion/svn/svn.c (working copy)
@@ -2409,7 +2409,7 @@
SVN_ERR(svn_stringbuf_from_file2(&buffer, utf8_opt_arg, pool));
SVN_ERR(svn_utf_stringbuf_to_utf8(&buffer_utf8, buffer, pool));
opt_state.targets =
svn_cstring_split(buffer_utf8->data, "\n\r",
- TRUE, pool);
+ FALSE, pool);
}
break;
case opt_force:
]]]
Note: Of course, file names endts with spaces can be add
by passing exact the file name to svn add, e.g. with most
shells on Unix like OS,
$ svn add '/Users/abc/trunk/aa '
or
$ svn add /Users/abc/trunk/aa\
~ one space here.
Cheers,
--
Yasuhito FUTATSUKI <futat...@yf.bsdclub.org>
Hi,
Best as I can tell this was changed in r842098
<https://svn.apache.org/r842098> where the original call to
svn_cl__newline_to_array() was replaced with svn_cstring_split() with
the TRUE argument:
[[[
@@ -950,7 +949,8 @@
svn_pool_destroy (pool);
return EXIT_FAILURE;
}
- opt_state.targets = svn_cl__newlinelist_to_array(buffer, pool);
+ opt_state.targets = svn_cstring_split (buffer->data, "\n\r",
+ TRUE, pool);
]]]
If I'm reading the code right (the function
svn_cl__newlinelist_to_array() was removed in 842098 so you need to do
`svn cat subversion/clients/cmdline/util.c@842097`), LEADING
whitespace was removed/ignored but trailing whitespace was kept
intact. The change above would resolve the reported issue but also
keeping leading whitespace.
For the record, r842098 was committed in 2002!
So I see a few different possible actions
1. Keep current behaviour (basically declaring this works as
expected). This has been the behaviour since at least Subversion 1.1.
2. Commit the patch above, changing behaviour for those relying on
trimming preceding (and possibly trailing) whitespace.
3. Recreating behaviour of svn_cl__newlinelist_to_array() by adding a
separate parameter to svn_cstring_split() so we can control separately
the removal of preceding and trailing whitespace. (This is public API
so we need to create a new svn_cstring_split2()).
I personally think it should be possible to specify any legal
filenames in the --targets file. Files with preceding or trailing
whitespace is possible under Linux. It seems NTFS also allow this but
the Windows shell trim both ends, cmd.exe allow creating files with
preceding whitespace. I haven't checked macOS.
I'm less inclined to restore the original behaviour (ie option 3)
since it files with preceding whitespace would still not be possible
to specify in the --targets file AND we would create regressions for
people who expect trailing whitespace to be trimmed.
Thus I'm leaning towards 2, even though it may create a regression for
any user of Subversion 1.1 or later. Let's call it +0.8.
Before you decide to "let's do it because it's possible", think about
what such file names are good for. Other than confusing people, that is,
or even creating some malicious repository.
Consider the consequences:
* Users won't see the trailing spaces in any file manager or shell.
* You can't manipulate such files at all, using the Windows command line.
* Such a change would not be backward compatible.
While you can do pretty much anything in Unix shells, the question is --
should you? I think this "use case" falls in the same category as
committing files with \ or ^H (that's backspace) in their names.
Here's an example:
brane@zulu:~/src/bs$ /bin/ls -wl
total 0
-rw-r--r-- 1 brane staff 0 Jun 17 15:49 foo.c
-rw-r--r-- 1 brane staff 0 Jun 17 15:48 foo.c
-rw-r--r-- 1 brane staff 0 Jun 17 15:49 foo.c
All three file names are unique. Which of them have trailing spaces?
Hint: only one ... but hey, that's neat! We can rename all of
Subversion's files and directories to look like 'foo' or 'foo.c',
wouldn't that be nice?
TL;DR: Leave well enough alone. One can already do any amount of
mischief with a Unix shell, or by creating files programmatically.
There's really no need to add one more avenue for confusion by "fixing"
--targets.
-- Brane
