fault) created prior to recursing into the sub‐dirs.   This  ear‐
              lier creation point (compared to a non‐incremental recursion) al‐
              lows  rsync to then set the modify time of the finished directory
              right away (without having to delay that until a bunch of  recur‐
              sive  copying  has  finished).   However, these early directories
              don’t yet have their completed mode, mtime, or  ownership  set --
              they  have more restrictive rights until the subdirectory’s copy‐
              ing actually begins.  This early‐creation idiom can be avoided by
              using the --omit‐dir‐times option.

              Incremental recursion can be disabled using  the  --no‐inc‐recur‐
              sive (--no‐i‐r) option.

       --no‐inc‐recursive, --no‐i‐r
              Disables  the new incremental recursion algorithm of the --recur‐
              sive option.  This makes rsync scan the full file list before  it
              begins to transfer files.  See --inc‐recursive for more info.

       --relative, -R
              Use  relative  paths.  This means that the full path names speci‐
              fied on the command line are sent to the server rather than  just
              the  last  parts  of  the filenames.  This is particularly useful
              when you want to send several different directories at  the  same
              time.  For example, if you used this command:

                  rsync ‐av /foo/bar/baz.c remote:/tmp/

              would  create  a file named baz.c in /tmp/ on the remote machine.
              If instead you used

                  rsync ‐avR /foo/bar/baz.c remote:/tmp/

              then a file named /tmp/foo/bar/baz.c would be created on the  re‐
              mote  machine,  preserving  its full path.  These extra path ele‐
              ments are called "implied directories" (i.e. the  "foo"  and  the
              "foo/bar" directories in the above example).

              Beginning  with rsync 3.0.0, rsync always sends these implied di‐
              rectories as real directories in the file list, even  if  a  path
              element  is  really a symlink on the sending side.  This prevents
              some really unexpected behaviors when copying the full path of  a
              file  that  you didn’t realize had a symlink in its path.  If you
              want to duplicate a server‐side symlink, include both the symlink
              via its path, and referent  directory  via  its  real  path.   If
              you’re  dealing  with an older rsync on the sending side, you may
              need to use the --no‐implied‐dirs option.

              It is also possible to limit the amount of path information  that
              is sent as implied directories for each path you specify.  With a
              modern  rsync on the sending side (beginning with 2.6.7), you can
              insert a dot and a slash into the source path, like this:

                  rsync ‐avR /foo/./bar/baz.c remote:/tmp/

              That would create /tmp/bar/baz.c on  the  remote  machine.  (Note
              that  the  dot must be followed by a slash, so "/foo/." would not
              be abbreviated.) For older rsync versions, you would need to  use
              a  chdir  to  limit  the  source path.  For example, when pushing
              files:

                  (cd /foo; rsync ‐avR bar/baz.c remote:/tmp/)

              (Note that the parens put the two commands into a  sub‐shell,  so
              that  the  "cd"  command doesn’t remain in effect for future com‐
              mands.) If you’re pulling files from an older rsync, use this id‐
              iom (but only for a non‐daemon transfer):

                  rsync ‐avR ‐‐rsync‐path="cd /foo; rsync" \
                       remote:bar/baz.c /tmp/

       --no‐implied‐dirs
              This option affects the default behavior of  the  --relative  op‐