I am new to Linux and am trying to rsync from one server to another. The servers have the same directory structure but I am having trouble getting the remotes server to properly recognize the path name on the remote when there is a space in it.

Here are the details

The local directory is

mnt/xlses/split/v2/name with space

The remote directory is

mnt/xlses/split/v2/name with space

I have tried everything I can find the latest attempt was

rsync --size-only -avzPe ssh  /mnt/xlses/split/v2/name\ with\ space/ root@myserver.com:/mnt/xlses/split/v2/"name with space"

when that runs the first thing it reports is that it is creating a new directory

I interrupt it and see that there is a new directory

mnt/xlses/split/v2/name

all of my files are in that directory

I was expecting them to be in

mnt/xlses/split/v2/name with space

11 Answers 11

up vote 6 down vote accepted

Try

rsync --size-only -avzPe ssh /mnt/xlses/split/v2/name\ with\ space root@myserver.com:/mnt/xlses/split/v2/

I took off the trailing slash / from the source directory path. This will make rsync copy the directory and all its contents, which means rsync will worry about getting the name correct on the remote host (which it will) instead of you.

  • 8
    This didn't work for me, but the answer by johnLate did. – Adriaan Feb 9 '15 at 16:17
  • This doesn't explain how to deal with spaces on the remote side. – ckujau Sep 21 '17 at 21:36

Try

rsync --protect-args --size-only -avzPe ssh  "/mnt/xlses/split/v2/name with space/ "root@myserver.com:/mnt/xlses/split/v2/name with space"

From man rsync:

-s, --protect-args

This option sends all filenames and most options to the remote rsync without allowing the remote shell to interpret them. This means that spaces are not split in names, and any non-wildcard special characters are not translated (such as ~, $, ;, &, etc.). Wildcards are expanded on the remote host by rsync (instead of the shell doing it). [...]

  • 10
    This doesn't work for Mac. – Matt Alexander Sep 25 '14 at 21:33
  • 5
    Works on the Mac if you install a recent version of rsync using home-brew. – Adriaan Feb 9 '15 at 16:17
  • 4
    See if it's in your version of rsync by running man rsync and searching (/s) for "--protect". To install with homebrew: brew install homebrew/dupes/rsync If not found run brew search rsync. – MikeiLL Jun 1 '15 at 17:08
  • 8
    New version install is unnecessary, you just escape spaces AND quote the host/filename - e.g. rsync -Pavuz 'you@host:~/file\ with\ spaces' ./ – ocodo Dec 11 '15 at 9:33

This works in bash: Escape the spaces with backslash and then use quotes:

rsync -avuz me@some.server.com:"/media/Music/Heavy\ Metal/Witch\ Mountain/*" .

Or if you have the path in the variable $remote_path, spaces can be escaped with substitution:

rsync -avuz me@some.server.com:"${remote_path// /\\ }" .
  • 1
    That worked for me. Saved me from having to work on a Mac server. – George Oct 29 '15 at 20:17
  • 1
    This should be marked the correct answer. The key is that you need both backslashes and quotes. – user7000 Apr 14 '16 at 17:33
  • 3
    Double-escaping is a pain, the -s option works on any modern version of rsync and is designed to solve this problem – Mark K Cowan Jul 23 '16 at 21:14
  • Note: if you're copying from a remote server with a space in path to a local path with space, you only need to add the quotes to the remote path. – lenooh Oct 2 at 14:46

I understand this is a old question, but I thought I would add to the existing body of knowledge.

I have used rsync with multiple folders with space and this works. I have folders numbered from 1-10 as follows:

  • The\ Folder1
  • The\ Folder2
  • The\ Folder3
  • ..
  • The\ Folder10

The 2 instances you would want to use rsync is local and remote.

  1. Local - Note the lack of quotes.

    rsync -avu /media/data/The\ Folder* .
    
  2. Remote - Note the presence of quotes

    rsync -avu -e ssh you@domain.com:"/media/data/The\ Folder*" .
    

Use two pairs of quotes

Don't bother with all the backslashes, just use single quotes inside double quotes:

ssh me@myserver.com:"'/home/me/test file'" .

You can also use the reverse, that is, double quotes inside single quotes:

ssh me@myserver.com:'"/home/me/test file"' .

Further info

The advantage, compared to the --protect-args solution, is that you actually do not have the restrictions of the --protect-args, so you can use special characters such as ~ or $. So you can write:

rsync host:'"$HOME/test file"' .

or

rsync host:'~"/test file"' .

Note that the tilde (~) in the latter example needs to be outside the double quotes.

You can put one of the pairs of quotes around the entire username@host:file part (e.g. ssh "me@myserver.com:'/home/me/test file'" .)

  • Actually your suggestion of not putting the host part in quotes at all is more insightful so it's tempting to make this the first line in the post. – user7000 Jun 29 at 0:26
  • 1
    This solution is brilliant! Worked as it was on the tin with rsync over ssh. – Ikon Jul 15 at 19:22
  • When you think about it, the 2 pairs of quotes are completely logical: the outer pair of quotes is so that the client treats it indivisibly (the contents of which are passed to the server verbatim) and the inner pair of quotes is for the server to recognize the indivisibility. – user7000 Oct 12 at 21:16

Generally speaking, quote the argument and escape the space characters in the argument. In the example you gave, try:

rsync --size-only -avzPe ssh  "/mnt/xlses/split/v2/name\ with\ space/" "root@myserver.com:/mnt/xlses/split/v2/name\ with\ space"

Well I am going to answer this question myself though someone else might do a better job of explaining it.

Evidently the setup on the destination machine affects how arguments are parsed and we must have something setup that is making it difficult to use quotes or slashes to escape spaces but we can use wild cards so I did this

rsync --size-only -avzPe ssh  /mnt/xlses/split/v2/name\ with\ space/ root@myserver.com:/mnt/xlses/split/v2/name*

This works for me because there is only one directory that begins with name if I had multiple directories this would not work.

Ultimately I need to understand how to setup the remote server so that it can parse the path name more efficiently - I never use spaces in directory names but the person who set this up did and at least for now I am stuck

  • Your proposal only works because you already created the destination directory during your first (unsuccessful) attempt. See my answer for an easier way (that also has the advantage of not relying on a failed first attempt :). – dg99 Dec 10 '13 at 23:02
  • Well actually the directory already existed. You are not correct in my failed attempt it created the directory /~/name not /~/name with Space I deleted /~/name and kept trying different options The directory /~/name with space existed already I was trying to add files to it – PyNEwbie Dec 10 '13 at 23:21
  • Oh, I see what you mean. – dg99 Dec 11 '13 at 0:12
  • Works if you quote the host/path as well as escape the spaces. – ocodo Dec 11 '15 at 9:34

Depending on the situation, a quick option is to create a symlink on the remote system:

user@remote$ ln -s ~/name\ with\ space/ ~/name_with_space

Then use the -L flag in rsync which tells it to follow directory contents:

user@local$ rsync -avz -L user@remote:~/name_with_space/ ~/name\ with\ space
  • I like the thinking, there are times when symlinking bypasses the hassle of bad naming or unnecessarily complex hierarchies. – user7000 Jun 29 at 0:24
rsync /mnt/xlses/split/v2/name\\\ with\\\ space/ root@myserver.com:/mnt/xlses/split/v2/name\\\ with\\\ space

double escape works too

From the rsync manpages:

   If you need to transfer a filename  that  contains  whitespace,  you  can
   either  specify  the --protect-args (-s) option, or you'll need to escape
   the whitespace in a way that  the  remote  shell  will  understand.   For
   instance:

          rsync -av host:'file\ name\ with\ spaces' /dest

Try this way:

find /path/ -exec rsync -A -X -av -r -s root@xxxx:/path/ {} \;

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.