pening to it and you want to make sure that  root‐level  read  or
              write  actions of system files are not possible.  While you could
              alternatively run all of rsync as the specified  user,  sometimes
              you  need  the  root‐level host‐access credentials to be used, so
              this allows rsync to drop root for the copying part of the opera‐
              tion after the remote‐shell or daemon connection is established.

              The option only affects one  side  of  the  transfer  unless  the
              transfer  is local, in which case it affects both sides.  Use the
              --remote‐option to affect the  remote  side,  such  as  -M--copy‐
              as=joe.   For  a local transfer, the lsh (or lsh.sh) support file
              provides a local‐shell helper script that can be used to allow  a
              "localhost:"  or  "lh:" host‐spec to be specified without needing
              to setup any remote shells, allowing you to  specify  remote  op‐
              tions  that  affect  the  side  of the transfer that is using the
              host‐spec (and using hostname "lh" avoids the overriding  of  the
              remote directory to the user’s home dir).

              For  example,  the following rsync writes the local files as user
              "joe":

                  sudo rsync ‐aiv ‐‐copy‐as=joe host1:backups/joe/ /home/joe/

              This makes all files owned by user "joe", limits  the  groups  to
              those  that  are  available to that user, and makes it impossible
              for the joe user to do a timed exploit of the path  to  induce  a
              change to a file that the joe user has no permissions to change.

              The  following  command does a local copy into the "dest/" dir as
              user "joe" (assuming you’ve installed support/lsh into a  dir  on
              your $PATH):

                  sudo rsync ‐aive lsh ‐M‐‐copy‐as=joe src/ lh:dest/

       --temp‐dir=DIR, -T
              This  option  instructs  rsync  to use DIR as a scratch directory
              when creating temporary copies of the files  transferred  on  the
              receiving side.  The default behavior is to create each temporary
              file  in  the  same directory as the associated destination file.
              Beginning with rsync 3.1.1, the temp‐file names inside the speci‐
              fied DIR will not be prefixed with an extra dot (though they will
              still have a random suffix added).

              This option is most often used when the receiving disk  partition
              does  not  have  enough  free space to hold a copy of the largest
              file in the transfer.  In this case (i.e. when the scratch direc‐
              tory is on a different disk partition), rsync will not be able to
              rename each received temporary file over the top of  the  associ‐
              ated  destination  file,  but  instead  must  copy it into place.
              Rsync does this by copying the file over the top of the  destina‐
              tion  file,  which  means  that the destination file will contain
              truncated data during this copy.  If this were not done this  way
              (even  if  the  destination file were first removed, the data lo‐
              cally copied to a temporary file in  the  destination  directory,
              and  then  renamed  into  place) it would be possible for the old
              file to continue taking up disk space (if someone had  it  open),
              and thus there might not be enough room to fit the new version on
              the disk at the same time.

              If you are using this option for reasons other than a shortage of
              disk  space,  you may wish to combine it with the --delay‐updates
              option, which will ensure that all copied files get put into sub‐
              directories in