Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #92745 > unrolled thread

Another interesting (?) scp/rsync problem.

Back to article view | Back to comp.os.linux.misc

Contents

  Another interesting (?) scp/rsync problem. gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-03 10:23 +0000
    Re: Another interesting (?) scp/rsync problem. The Natural Philosopher <tnp@invalid.invalid> - 2026-10-03 11:50 +0100
    Re: Another interesting (?) scp/rsync problem. Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-10-03 11:00 +0000
      Re: Another interesting (?) scp/rsync problem. Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-10-03 11:08 +0000
      Re: Another interesting (?) scp/rsync problem. Richard Kettlewell <invalid@invalid.invalid> - 2026-10-03 16:01 +0100
        Re: Another interesting (?) scp/rsync problem. gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-03 17:51 +0000
        Re: Another interesting (?) scp/rsync problem. Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-10-04 10:59 +0000
          Re: Another interesting (?) scp/rsync problem. gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-04 12:28 +0000
    Re: Another interesting (?) scp/rsync problem. Rich <rich@example.invalid> - 2026-10-03 13:06 +0000
      Re: Another interesting (?) scp/rsync problem. Richard Kettlewell <invalid@invalid.invalid> - 2026-10-03 16:04 +0100
    Re: Another interesting (?) scp/rsync problem. Richard Kettlewell <invalid@invalid.invalid> - 2026-10-03 15:58 +0100
    Re: Another interesting (?) scp/rsync problem. c186282 <c186282@nnada.net> - 2026-10-03 23:23 -0400
    Re: Another interesting (?) scp/rsync problem. "Carlos E. R." <robin_listas@es.invalid> - 2026-10-04 12:46 +0200
      Re: Another interesting (?) scp/rsync problem. gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-04 12:29 +0000
        Re: Another interesting (?) scp/rsync problem. "Carlos E. R." <robin_listas@es.invalid> - 2026-10-04 15:09 +0200
          Re: Another interesting (?) scp/rsync problem. gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-04 14:10 +0000
            Re: Another interesting (?) scp/rsync problem. The Natural Philosopher <tnp@invalid.invalid> - 2026-10-04 18:06 +0100
              Re: Another interesting (?) scp/rsync problem. "Carlos E. R." <robin_listas@es.invalid> - 2026-10-04 19:31 +0200
                Re: Another interesting (?) scp/rsync problem. The Natural Philosopher <tnp@invalid.invalid> - 2026-10-04 18:58 +0100
                  Re: Another interesting (?) scp/rsync problem. "Carlos E. R." <robin_listas@es.invalid> - 2026-10-04 20:31 +0200
        Re: Another interesting (?) scp/rsync problem. c186282 <c186282@nnada.net> - 2026-10-05 02:37 -0400
          Re: Another interesting (?) scp/rsync problem. Richard Kettlewell <invalid@invalid.invalid> - 2026-10-05 09:05 +0100
            Re: Another interesting (?) scp/rsync problem. Rich <rich@example.invalid> - 2026-10-05 17:52 +0000
      Re: Another interesting (?) scp/rsync problem. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-05 02:31 +0000

Page 1 of 2  [1] 2  Next page →

#92745 — Another interesting (?) scp/rsync problem.

Ran into this today.  Note that I started with "scp", hit the problem, so
tried "rsync" next - same problem (exactly, suggesting that they use the same
underlying mechanism - then switched to "sftp", which worked (albeit
interactively, not fully command-line).

So, I have a file on a remote system whose name has spaces in it - say

    $HOME/path/to/foo bar

The directory path/to has lots of other files in it; I just want to copy
"foo bar" to a local system.  Assume that this file is the only one
starting with "foo" in that directory, so the pattern "foo*" will match it.
Also, assume that the actual filename is much longer and complicated and I
am explicitly trying to avoid typing in the whole name.  I want to match it
with just "foo*".

So, I try:

    scp -p remotesys:path/to/foo* .

and I get error messages, basically complaining that there's no file "foo"
and there's no file "bar".  It seems clear that what it did was to glob
"foo*" on the remote system (which is good), then run it through some
shell (some version of /bin/sh) which caused it to get word-split into its
component parts (which is bad).

I tried many different things, but could not get anything to work, with
either "scp" or "rsync".  As mentioned above, eventually, "sftp" did the
trick, since its interactive mode has filename completion, so I was able to
do:

    sftp> get -p foo<tab>

and have it do the right thing.

Note: I tried doing this with (various combinations of) --include and
--exclude in "rsync", but nothing worked.

Any advice?

-- 
The randomly chosen signature file that would have appeared here is more than 4-ish
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/RepInsults

[toc] | [next] | [standalone]

#92746

On 03/10/2026 11:23, Kenny McCormack wrote:
> Ran into this today.  Note that I started with "scp", hit the problem, so
> tried "rsync" next - same problem (exactly, suggesting that they use the same
> underlying mechanism - then switched to "sftp", which worked (albeit
> interactively, not fully command-line).
> 
> So, I have a file on a remote system whose name has spaces in it - say
> 
>      $HOME/path/to/foo bar
> 
> The directory path/to has lots of other files in it; I just want to copy
> "foo bar" to a local system.  Assume that this file is the only one
> starting with "foo" in that directory, so the pattern "foo*" will match it.
> Also, assume that the actual filename is much longer and complicated and I
> am explicitly trying to avoid typing in the whole name.  I want to match it
> with just "foo*".
> 
> So, I try:
> 
>      scp -p remotesys:path/to/foo* .
> 
> and I get error messages, basically complaining that there's no file "foo"
> and there's no file "bar".  It seems clear that what it did was to glob
> "foo*" on the remote system (which is good), then run it through some
> shell (some version of /bin/sh) which caused it to get word-split into its
> component parts (which is bad).
> 
> I tried many different things, but could not get anything to work, with
> either "scp" or "rsync".  As mentioned above, eventually, "sftp" did the
> trick, since its interactive mode has filename completion, so I was able to
> do:
> 
>      sftp> get -p foo<tab>
> 
> and have it do the right thing.
> 
> Note: I tried doing this with (various combinations of) --include and
> --exclude in "rsync", but nothing worked.
> 
> Any advice?
> 

Surely  scp -p "remotesys:path/to/foo bar" . should work?

or  scp -p remotesys:path/to/foo\ bar...

A quick google reveals that this is not a new problem

Or one without several solutions

-- 
Climate Change: Socialism wearing a lab coat.

[toc] | [prev] | [next] | [standalone]

#92748

Le 03-10-2026, Kenny McCormack <gazelle@shell.xmission.com> a écrit :
>
> Any advice?

Did you tried to escape the star or the space? Like "foo*" or foo\ ?
Because the start is never seen by scp or by rsync. So what's sent to
scp or rsync is not the star but the result of it's treatment by the
SHELL.

I mean, when you send "ls $HOME/foo*", "ls" doesn't see "$HOME/foo*", it
sees "/home/toto/foo bar". Without the quotes. Which means, it sees two
files: "/home/toto/foo" and "bar". Because arguments are terminated by
spaces, it has to be escaped. And it can be tricky. I don't know if
rsync or scp have way to change this behavior. For example, there is an
option in xargs designed to that: -0.

I don't know how manage it, but it's the way to look for.

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[toc] | [prev] | [next] | [standalone]

#92750

Le 03-10-2026, Stéphane CARPENTIER <sc@fiat-linux.fr> a écrit :
> Le 03-10-2026, Kenny McCormack <gazelle@shell.xmission.com> a écrit :
>>
>> Any advice?
>
> Did you tried to escape the star or the space? Like "foo*" or foo\ ?

For the second, I mean «foo\ *» (an escaped space before the star).

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[toc] | [prev] | [next] | [standalone]

#92765

Stéphane CARPENTIER <sc@fiat-linux.fr> writes:
> Le 03-10-2026, Kenny McCormack <gazelle@shell.xmission.com> a écrit :
>
>> Any advice?
>
> Did you tried to escape the star or the space? Like "foo*" or foo\ ?
> Because the start is never seen by scp or by rsync. So what's sent to
> scp or rsync is not the star but the result of it's treatment by the
> SHELL.

Unless Kenny has some very strange filenames (or an unusual shell
configuration), the local shell will leave remotesys:path/to/foo*
untouched, because no filenames match it:

    richard@sfere:~$ echo remotesys:path/to/foo*
    remotesys:path/to/foo*

The problem is that older versions of scp put everything through the
server-side shell, as described in my other post.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#92770

In article <wwvo6dan7z5.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell  <invalid@invalid.invalid> wrote:
>Stphane CARPENTIER <sc@fiat-linux.fr> writes:
>> Le 03-10-2026, Kenny McCormack <gazelle@shell.xmission.com> a crit:
>>
>>> Any advice?
>>
>> Did you tried to escape the star or the space? Like "foo*" or foo\ ?
>> Because the start is never seen by scp or by rsync. So what's sent to
>> scp or rsync is not the star but the result of it's treatment by the
>> SHELL.
>
>Unless Kenny has some very strange filenames (or an unusual shell
>configuration), the local shell will leave remotesys:path/to/foo*
>untouched, because no filenames match it:

Right.  It is a feature of the Bourne-ish shells that if a glob doesn't
match, it is passed unchanged.  I think "Stphane" knows this, but seems to
assume that I don't.  Note that the csh-ish shells take the other tack:
That if a glob doesn't expand, it is an error.  Also, in bash (at least;
maybe others) you can set "nullglob", which makes things that don't expand
eval to nothing.  I actually think that if I were designing a shell from
scratch, I'd make nullglob the default - in fact, only - behavior.  This is
better (IMHO) than either the 'sh' or 'csh' approaches (**).

So, even though you really should quote everything, I often rely on the
fact that I can pass something that looks like a glob unquoted, and get
away with it (because I know it won't match anything locally).

Anyway, glad to know that this is just an "old version problem" and that it
is fixed in current versions.  Note, BTW, that I've had to deal with the
"quote it twice" issue with 'ssh' (*), but I didn't know until today that
it could arise with "scp" (and "rsync") as well.

(*) When you supply a command on the "ssh" command line, sometimes you have
to quote it twice - usually something like: "'foo'"

(**) Setting "nullglob" is dangerous, though, because it makes a lot of
things in the shell not work as expected; it has weird side effects.

-- 
 "They say if you play a Microsoft CD backwards, you hear satanic messages.
  Thats nothing, cause if you play it forwards, it installs Windows."

[toc] | [prev] | [next] | [standalone]

#92823

Le 03-10-2026, Richard Kettlewell <invalid@invalid.invalid> a écrit :
> Stéphane CARPENTIER <sc@fiat-linux.fr> writes:
>> Le 03-10-2026, Kenny McCormack <gazelle@shell.xmission.com> a écrit :
>>
>>> Any advice?
>>
>> Did you tried to escape the star or the space? Like "foo*" or foo\ ?
>> Because the start is never seen by scp or by rsync. So what's sent to
>> scp or rsync is not the star but the result of it's treatment by the
>> SHELL.
>
> Unless Kenny has some very strange filenames (or an unusual shell
> configuration), the local shell will leave remotesys:path/to/foo*
> untouched, because no filenames match it:
>
>     richard@sfere:~$ echo remotesys:path/to/foo*
>     remotesys:path/to/foo*
>
> The problem is that older versions of scp put everything through the
> server-side shell, as described in my other post.

Yesterday, I didn't had a lot of time before answering and realised
after that that what I said couldn't have work. I know shell, but I'm
not familiar with scp and rsync. So reading his message, I guessed,
rightly, that scp and rsync were sending their commands to the shell.

But I didn't guessed that it was a bug. And even if it wasn't a bug, my
answer wouldn't have been accurate. Because his issue wasn't to escape
the space from the shell, but to escape the space returned by the shell.

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[toc] | [prev] | [next] | [standalone]

#92829

In article <6ac231a3$0$11422$426a74cc@news.free.fr>,
Stphane CARPENTIER  <sc@fiat-linux.fr> wrote:
...
>Because his issue wasn't to escape
>the space from the shell, but to escape the space returned by the shell.

Actually, my "issue" was just that I am running old(er) versions of the
tools.  The obvious fix would be to "upgrade" the tools, but note that
that's not really an option in my circumstances.  As I said, using "sftp"
turns out to be the best workaround.

-- 
The randomly chosen signature file that would have appeared here is more than 4-ish
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/DanaC

[toc] | [prev] | [next] | [standalone]

#92761

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> The directory path/to has lots of other files in it; I just want to copy
> "foo bar" to a local system.  Assume that this file is the only one
> starting with "foo" in that directory, so the pattern "foo*" will match it.
> Also, assume that the actual filename is much longer and complicated and I
> am explicitly trying to avoid typing in the whole name.  I want to match it
> with just "foo*".
> 
> So, I try:
> 
>     scp -p remotesys:path/to/foo* .

Unable to recreate:

$ scp -p remote:path/to/foo* . 
foo bar

$ rsync remote:path/to/foo*
-rw-rw-r--              0 2026/10/03 08:47:50 foo bar

Now, you say the remote had no files beginning with 'foo'.  What about 
the local system?  Because your unquoted glob string there *will* match 
a foo* on the local system and if that happens you will likely get an 
error because what matches locally may not exist remotely.

If I make a "remote:path/to/" dir, and put into it a "foo local" file, 
then rerun the command, I get your error:

$ scp -p remote:path/to/foo* . 
scp: path/to/foo: No such file or directory
scp: local: No such file or directory

Quoting the glob makes it work again:

$ scp -p "remote:path/to/foo*" . 
foo bar


Now, you do need "remote:path/to/foo*" to exist locally.  And the way 
you might end up with "remote:" existing locally is some, earlier, 
mistyped scp command ended up creating "remote:path/to" locally for 
you.


It's easy to forget, but in Unix shells, unlike Dos command.com, the 
globs are expanded by the shell.  The individual commands do not expand 
them.  And that means, for commands like 'scp' where you want the 
expansion to happen on the remote system, is that you need to tell your 
local shell to not do the expansion locally.  It works most of the time 
because you don't have a match in the local dir, so glob is passed 
untouched to the other side when nothing matches, but when it succeeds, 
you get weird error messages like what you describe.

You can see how your local shell is expanding the scp command by 
prefixing it with echo.  Note the differences below:

$ echo scp -p "remote:path/to/foo*" . 
scp -p remote:path/to/foo* .

$ echo scp -p remote:path/to/foo* . 
scp -p remote:path/to/foo local .

In the second case, what scp, on remote, is being asked to send is "foo 
local", which does not exist, not "foo*", because the * was expanded by 
bash on the local side before scp was ever invoked.

[toc] | [prev] | [next] | [standalone]

#92766

Rich <rich@example.invalid> writes:
> Unable to recreate:
>
> $ scp -p remote:path/to/foo* . 
> foo bar

You have scp from OpenSSH 9.0 or later (or some other variant that has
fixed scp).

> $ rsync remote:path/to/foo*
> -rw-rw-r--              0 2026/10/03 08:47:50 foo bar
>
> Now, you say the remote had no files beginning with 'foo'.  What about 
> the local system?  Because your unquoted glob string there *will* match 
> a foo* on the local system and if that happens you will likely get an 
> error because what matches locally may not exist remotely.

No, it won’t.

    richard@sfere:~$ ls -l foo\ bar 
    -rw-rw-r-- 1 richard richard 0 Oct  3 15:49 'foo bar'
    richard@sfere:~$ echo remotesys:foo*
    remotesys:foo*

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#92763

gazelle@shell.xmission.com (Kenny McCormack) writes:
> Ran into this today.  Note that I started with "scp", hit the problem,
> so tried "rsync" next - same problem (exactly, suggesting that they
> use the same underlying mechanism - then switched to "sftp", which
> worked (albeit interactively, not fully command-line).
>
> So, I have a file on a remote system whose name has spaces in it - say
>
>     $HOME/path/to/foo bar
>
> The directory path/to has lots of other files in it; I just want to
> copy "foo bar" to a local system.  Assume that this file is the only
> one starting with "foo" in that directory, so the pattern "foo*" will
> match it.  Also, assume that the actual filename is much longer and
> complicated and I am explicitly trying to avoid typing in the whole
> name.  I want to match it with just "foo*".
>
> So, I try:
>
>     scp -p remotesys:path/to/foo* .
>
> and I get error messages, basically complaining that there's no file
> "foo" and there's no file "bar".  It seems clear that what it did was
> to glob "foo*" on the remote system (which is good), then run it
> through some shell (some version of /bin/sh) which caused it to get
> word-split into its component parts (which is bad).

This used to be a well-known bug in scp; it put everything through the
remote shell, so you need an extra level of shell quoting; one to get
through your local shell (if used) and another for the remote shell.  It
was fixed in OpenSSH 9.0 (see https://www.openssh.org/txt/release-9.0).

Here I have OpenSSH 10.0p1:

    richard@vitripane:~$ ls -l junk/
    total 0
    -rw-rw-r-- 1 richard richard 0 Oct  3 15:38 'foo bar'

    richard@sfere:~$ scp -p vitripane:junk/foo* .
    richard@sfere:~$ ls -l foo\ bar 
    -rw-rw-r-- 1 richard richard 0 Oct  3 15:38 'foo bar'
    richard@sfere:~$ rm foo\ bar 
    richard@sfere:~$ scp -p 'vitripane:junk/foo bar' .
    richard@sfere:~$ ls -l foo\ bar 
    -rw-rw-r-- 1 richard richard 0 Oct  3 15:38 'foo bar'

The old behavior, and the workaround required, can still be seen with
the -O option:

    richard@sfere:~$ rm foo\ bar 
    richard@sfere:~$ scp -O -p 'vitripane:junk/foo bar' .
    scp: junk/foo: No such file or directory
    scp: bar: No such file or directory
    richard@sfere:~$ 
    richard@sfere:~$ scp -O -p 'vitripane:junk/foo\ bar' .
    foo bar                                       100%    0     0.0KB/s   00:00

Modern rsync (here 3.5.0) works for me as well:

    richard@sfere:~$ rm foo\ bar 
    richard@sfere:~$ rsync 'vitripane:junk/foo bar' .
    richard@sfere:~$ ls -l foo\ bar 
    -rw-rw-r-- 1 richard richard 0 Oct  3 15:41 'foo bar'
    ichard@sfere:~$ rm foo\ bar 
    richard@sfere:~$ rsync vitripane:junk/foo\* .
    richard@sfere:~$ ls -l foo\ bar 
    -rw-rw-r-- 1 richard richard 0 Oct  3 15:49 'foo bar'
    richard@sfere:~$ 

It looks like older versions of rsync had the same bug as scp, with
modern versions having a --old-args version to restore the bug.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#92788

On 10/3/26 06:23, Kenny McCormack wrote:
> Ran into this today.  Note that I started with "scp", hit the problem, so
> tried "rsync" next - same problem (exactly, suggesting that they use the same
> underlying mechanism - then switched to "sftp", which worked (albeit
> interactively, not fully command-line).
> 
> So, I have a file on a remote system whose name has spaces in it - say
> 
>      $HOME/path/to/foo bar
> 
> The directory path/to has lots of other files in it; I just want to copy
> "foo bar" to a local system.  Assume that this file is the only one
> starting with "foo" in that directory, so the pattern "foo*" will match it.
> Also, assume that the actual filename is much longer and complicated and I
> am explicitly trying to avoid typing in the whole name.  I want to match it
> with just "foo*".
> 
> So, I try:
> 
>      scp -p remotesys:path/to/foo* .
> 
> and I get error messages, basically complaining that there's no file "foo"
> and there's no file "bar".  It seems clear that what it did was to glob
> "foo*" on the remote system (which is good), then run it through some
> shell (some version of /bin/sh) which caused it to get word-split into its
> component parts (which is bad).
> 
> I tried many different things, but could not get anything to work, with
> either "scp" or "rsync".  As mentioned above, eventually, "sftp" did the
> trick, since its interactive mode has filename completion, so I was able to
> do:
> 
>      sftp> get -p foo<tab>
> 
> and have it do the right thing.
> 
> Note: I tried doing this with (various combinations of) --include and
> --exclude in "rsync", but nothing worked.
> 
> Any advice?

   Do you have a firewall turned on ? If so, find the
   right ports to let through.

[toc] | [prev] | [next] | [standalone]

#92819

On 2026-10-03 12:23, Kenny McCormack wrote:
> Ran into this today.  Note that I started with "scp", hit the problem, so
> tried "rsync" next - same problem (exactly, suggesting that they use the same
> underlying mechanism - then switched to "sftp", which worked (albeit
> interactively, not fully command-line).
> 
> So, I have a file on a remote system whose name has spaces in it - say
> 
>      $HOME/path/to/foo bar
> 
> The directory path/to has lots of other files in it; I just want to copy
> "foo bar" to a local system.  Assume that this file is the only one
> starting with "foo" in that directory, so the pattern "foo*" will match it.
> Also, assume that the actual filename is much longer and complicated and I
> am explicitly trying to avoid typing in the whole name.  I want to match it
> with just "foo*".
> 
> So, I try:
> 
>      scp -p remotesys:path/to/foo* .
> 
> and I get error messages, basically complaining that there's no file "foo"
> and there's no file "bar".  It seems clear that what it did was to glob
> "foo*" on the remote system (which is good), then run it through some
> shell (some version of /bin/sh) which caused it to get word-split into its
> component parts (which is bad).
> 
> I tried many different things, but could not get anything to work, with
> either "scp" or "rsync".  As mentioned above, eventually, "sftp" did the
> trick, since its interactive mode has filename completion, so I was able to
> do:
> 
>      sftp> get -p foo<tab>
> 
> and have it do the right thing.
> 
> Note: I tried doing this with (various combinations of) --include and
> --exclude in "rsync", but nothing worked.
> 
> Any advice?

rsync -vart --size-only --progress --info=progress2 
"carlos@..:/home/public/Videos/TV/A B/A_B_S06"/ .

That works, I use it. Of course, you probably do not need all the 
options, but I left them because I pasted from the actual command used.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#92830

In article <niep4cF1toqU3@mid.individual.net>,
Carlos E. R. <robin_listas@es.invalid> wrote:
...
>rsync -vart --size-only --progress --info=progress2 
>"carlos@..:/home/public/Videos/TV/A B/A_B_S06"/ .

Part of the original problem description was that you could not write out
the entire filename of the target.  That would be cheating.

>That works, I use it. Of course, you probably do not need all the 
>options, but I left them because I pasted from the actual command used.
-- 
https://en.wikipedia.org/wiki/Mansplaining

    It describes comp.lang.c to a T!

[toc] | [prev] | [next] | [standalone]

#92831

On 2026-10-04 14:29, Kenny McCormack wrote:
> In article <niep4cF1toqU3@mid.individual.net>,
> Carlos E. R. <robin_listas@es.invalid> wrote:
> ...
>> rsync -vart --size-only --progress --info=progress2
>> "carlos@..:/home/public/Videos/TV/A B/A_B_S06"/ .
> 
> Part of the original problem description was that you could not write out
> the entire filename of the target.  That would be cheating.

I just tried:

rsync -vart --size-only --progress --info=progress2 
"carlos@..:/home/public/Videos/TV/A B/A_B_S0*"/ .

and it works.



-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#92833

In article <nif1fhF1toqU4@mid.individual.net>,
Carlos E. R. <robin_listas@es.invalid> wrote:
>On 2026-10-04 14:29, Kenny McCormack wrote:
>> In article <niep4cF1toqU3@mid.individual.net>,
>> Carlos E. R. <robin_listas@es.invalid> wrote:
>> ...
>>> rsync -vart --size-only --progress --info=progress2
>>> "carlos@..:/home/public/Videos/TV/A B/A_B_S06"/ .
>> 
>> Part of the original problem description was that you could not write out
>> the entire filename of the target.  That would be cheating.
>
>I just tried:
>
>rsync -vart --size-only --progress --info=progress2 
>"carlos@..:/home/public/Videos/TV/A B/A_B_S0*"/ .
>
>and it works.

You are probably running a sufficiently recent version  of the tools.

Remember, this whole issue is simply one of there being a very well known
bug in the old version(s) of scp/rsync, that is fixed in current versions.

So, really, nothing to see here.

-- 
Life's big questions are big in the sense that they are momentous.
However, contrary to appearances, they are not big in the sense of being
unanswerable.  It is only that the answers are generally unpalatable.
There is no great mystery, but there is plenty of horror.
    (https://en.wikiquote.org/wiki/David_Benatar)

[toc] | [prev] | [next] | [standalone]

#92841

On 04/10/2026 15:10, Kenny McCormack wrote:
> Remember, this whole issue is simply one of there being a very well known
> bug in the old version(s) of scp/rsync, that is fixed in current versions.
> 
> So, really, nothing to see here.
which is why I NFS crossmount my machines and used the GUI

-- 
The lifetime of any political organisation is about three years before 
its been subverted by the people it tried to warn you about.

Anon.

[toc] | [prev] | [next] | [standalone]

#92849

On 2026-10-04 19:06, The Natural Philosopher wrote:
> On 04/10/2026 15:10, Kenny McCormack wrote:
>> Remember, this whole issue is simply one of there being a very well known
>> bug in the old version(s) of scp/rsync, that is fixed in current 
>> versions.
>>
>> So, really, nothing to see here.
> which is why I NFS crossmount my machines and used the GUI
> 

sshfs and mc

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

#92854

On 04/10/2026 18:31, Carlos E. R. wrote:
> On 2026-10-04 19:06, The Natural Philosopher wrote:
>> On 04/10/2026 15:10, Kenny McCormack wrote:
>>> Remember, this whole issue is simply one of there being a very well 
>>> known
>>> bug in the old version(s) of scp/rsync, that is fixed in current 
>>> versions.
>>>
>>> So, really, nothing to see here.
>> which is why I NFS crossmount my machines and used the GUI
>>
> 
> sshfs and mc
> 
No one is snooping my networks.

-- 
“Puritanism: The haunting fear that someone, somewhere, may be happy.”

H.L. Mencken, A Mencken Chrestomathy

[toc] | [prev] | [next] | [standalone]

#92862

On 2026-10-04 19:58, The Natural Philosopher wrote:
> On 04/10/2026 18:31, Carlos E. R. wrote:
>> On 2026-10-04 19:06, The Natural Philosopher wrote:
>>> On 04/10/2026 15:10, Kenny McCormack wrote:
>>>> Remember, this whole issue is simply one of there being a very well 
>>>> known
>>>> bug in the old version(s) of scp/rsync, that is fixed in current 
>>>> versions.
>>>>
>>>> So, really, nothing to see here.
>>> which is why I NFS crossmount my machines and used the GUI
>>>
>>
>> sshfs and mc
>>
> No one is snooping my networks.

I'm using it right now over internet. In the LAN, it is just simple to use.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web