example, if src/*.c  matches  one
       file  and  save/dir  doesn’t  exist, this will confuse you by naming the
       destination file save/dir:

           rsync ‐ai src/*.c save/dir

       To prevent such an accident, either make sure the destination dir exists
       or specify the destination path with a trailing slash:

           rsync ‐ai src/*.c save/dir/

SORTED TRANSFER ORDER
       Rsync always sorts the specified filenames into  its  internal  transfer
       list.   This handles the merging together of the contents of identically
       named directories, makes it easy to remove duplicate filenames. It  can,
       however,  confuse  someone when the files are transferred in a different
       order than what was given on the command‐line.

       If you need a particular file to be transferred prior to another, either
       separate the files into different rsync calls, or consider  using  --de‐
       lay‐updates  (which  doesn’t  affect the sorted transfer order, but does
       make the final file‐updating phase happen much more rapidly).

MULTI‐HOST SECURITY
       Rsync takes steps to ensure that the file requests that are shared in  a
       transfer are protected against various security issues.  Most of the po‐
       tential  problems arise on the receiving side where rsync takes steps to
       ensure that the list of  files  being  transferred  remains  within  the
       bounds of what was requested.

       Toward  this  end,  rsync  3.1.2 and later have aborted when a file list
       contains an absolute or relative path that tries to escape  out  of  the
       top of the transfer.  Also, beginning with version 3.2.5, rsync does two
       more  safety  checks of the file list to (1) ensure that no extra source
       arguments were added into the transfer other than those that the  client
       requested and (2) ensure that the file list obeys the exclude rules that
       were sent to the sender.

       For  those  that don’t yet have a 3.2.5 client rsync (or those that want
       to be extra careful), it is safest to do a copy into a dedicated  desti‐
       nation  directory  for  the remote files when you don’t trust the remote
       host.  For example, instead of doing an rsync copy into your home direc‐
       tory:

           rsync ‐aiv host1:dir1 ~

       Dedicate a "host1‐files" dir to the remote content:

           rsync ‐aiv host1:dir1 ~/host1‐files

       See the --trust‐sender option for additional details.

       CAUTION: it is not particularly safe to use rsync to copy files  from  a
       case‐preserving  filesystem  to a case‐ignoring filesystem.  If you must
       perform such a copy, you should either disable symlinks  via  --no‐links
       or  enable  the munging of symlinks via --munge‐links (and make sure you
       use the right local or remote option).  This will prevent rsync from do‐
       ing potentially dangerous things if a symlink name overlaps with a  file
       or  directory.  It does not, however, ensure that you get a full copy of
       all the files (since that may not be possible when the names overlap). A
       potentially better solution is to list all the source files and create a
       safe list of filenames that you pass to the  --files‐from  option.   Any
       files  that conflict in name would need to be copied to different desti‐
       nation directories using more than one copy.

       While a copy of a case‐ignoring filesystem to a case‐ignoring filesystem
       can work out fairly well, if no --delete‐during or  --delete‐before  op‐
       tion is active, rsync can potentially update an existing file on the re‐
       ceiveing  side  without noticing that the upper‐/lower‐case of the file‐
       name should be changed to match the sender.

ADVANCED USAGE
       The syntax for requesting multiple files from a remote host is  done  by
       specifying  additional  remote‐host args in the same style as the first,
       or with