You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by 管理员 <ad...@han-soft.com> on 2025/06/16 09:06:32 UTC
filename ends with a space, cannot use the --targets option.
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
create a file: /Users/abc/trunk/2.txt, contents:
"/Users/abc/trunk/aaa"
"/Users/abc/trunk/aa "
execute svn command:
svn add --targets /Users/abc/trunk/2.txt
svn: warning: W155010: The node '/Users/abc/trunk/"/Users/abc/trunk' was not found.
svn: E200009: Could not add all targets because some targets don't exist
svn: E200009: Illegal target for the requested operation
create a file: /Users/abc/trunk/3.txt, contents:
/Users/abc/trunk/aaa
/Users/abc/trunk/aa\ // ends with a space.
execute svn command:
svn add --targets /Users/abc/trunk/3.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
Re: filename ends with a space, cannot use the --targets option.
Posted by Branko Čibej <br...@apache.org>.
On 17. 6. 25 09:45, Daniel Sahlberg wrote:
> 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 forgot about this example:
brane@zulu:~/src/bs$ touch "$(echo fileXname | tr 'X' '\n')"
brane@zulu:~/src/bs$ /bin/ls -wl
total 0
-rw-r--r-- 1 brane staff 0 Jun 17 18:09 file
name
You were saying, about "legal" filenames? Will you support this in the
--targets file as well? It is, after all, no more an exception than the
trailing spaces.
And, finally:
brane@zulu:~/src/bs$ touch "$(echo 'fileX[1;31mnameX[0;m' | tr 'X' '\033')"
brane@zulu:~/src/bs$ /bin/ls -wl
total 0
-rw-r--r-- 1 brane staff 0 Jun 17 18:19 filename
This one doesn't even have any hidden whitespace. And we do already
support this in --targets. :)
-- Brane
Re: filename ends with a space, cannot use the --targets option.
Posted by Daniel Sahlberg <da...@gmail.com>.
Den fre 27 juni 2025 kl 15:08 skrev Branko Čibej <br...@apache.org>:
> On 27. 6. 25 11:54, Daniel Sahlberg wrote:
>
> Den tis 17 juni 2025 kl 15:58 skrev Branko Čibej <br...@apache.org>:
>
>> 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.
>>
>
> Makes sense to me. Should we document this some way in svn help? Currently:
> [[[
> $ svn help add
> [...]
> Valid options:
> --targets ARG : pass contents of file ARG as additional args
> [...]
> ]]]
>
> We could update the svnbook as well, it currently says:
> [[[
> --targets *FILENAME*
>
> Tells Subversion to read additional target paths for the operation from
> *FILENAME*. *FILENAME* should contain one path per line, with each path
> expected to use the same encoding and formatting that it would if you had
> specified it directly as an argument on the command line.
> ]]]
>
>
>
> I'm sorry, what's there to fix?
>
To document that there are some filenames which, while valid in the file
system, are not possible to use in the file pointed to by --targets.
Basically, have something to point at and say "works as expected" when the
question from the original poster comes up again.
Cheers,
Daniel
Re: filename ends with a space, cannot use the --targets option.
Posted by Branko Čibej <br...@apache.org>.
On 27. 6. 25 11:54, Daniel Sahlberg wrote:
> Den tis 17 juni 2025 kl 15:58 skrev Branko Čibej <br...@apache.org>:
>
> 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.
>
>
> Makes sense to me. Should we document this some way in svn help?
> Currently:
> [[[
> $ svn help add
> [...]
> Valid options:
> --targets ARG : pass contents of file ARG as additional args
> [...]
> ]]]
>
> We could update the svnbook as well, it currently says:
> [[[
> |--targets|/|FILENAME|/
>
> Tells Subversion to read additional target paths for the operation
> from /|FILENAME|/. /|FILENAME|/ should contain one path per line,
> with each path expected to use the same encoding and formatting
> that it would if you had specified it directly as an argument on
> the command line.
>
> ]]]
>
>
I'm sorry, what's there to fix? This is perfectly true. Do not confuse
"the command line" with "something some shell somewhere allows you to
do". --targets is supposed to help scripting, not support nonsense. I've
not yet heard one argument for supporting filenames with trailing spaces
in those files other than "bash can do it".
Well, it's not bash.
-- Brane
Re: filename ends with a space, cannot use the --targets option.
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 17 juni 2025 kl 15:58 skrev Branko Čibej <br...@apache.org>:
> 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.
>
Makes sense to me. Should we document this some way in svn help? Currently:
[[[
$ svn help add
[...]
Valid options:
--targets ARG : pass contents of file ARG as additional args
[...]
]]]
We could update the svnbook as well, it currently says:
[[[
--targets *FILENAME*
Tells Subversion to read additional target paths for the operation from
*FILENAME*. *FILENAME* should contain one path per line, with each path
expected to use the same encoding and formatting that it would if you had
specified it directly as an argument on the command line.
]]]
Cheers,
Daniel
Re: filename ends with a space, cannot use the --targets option.
Posted by Branko Čibej <br...@apache.org>.
On 17. 6. 25 09:45, Daniel Sahlberg wrote:
> Den tis 17 juni 2025 kl 06:24 skrev Yasuhito FUTATSUKI
> <fu...@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 <fu...@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
Re: filename ends with a space, cannot use the --targets option.
Posted by Ryan Carsten Schmidt <su...@ryandesign.com>.
On Jun 17, 2025, at 02:45, Daniel Sahlberg wrote:
> 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.
macOS, being a POSIX-compliant Unix, of course supports all legal filenames including those beginning or ending with spaces.
Re: filename ends with a space, cannot use the --targets option.
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 17 juni 2025 kl 06:24 skrev Yasuhito FUTATSUKI <
futatuki@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 <fu...@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.
Cheers,
Daniel
Re: filename ends with a space, cannot use the --targets option.
Posted by Yasuhito FUTATSUKI <fu...@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 <fu...@yf.bsdclub.org>