Is rsync really bidirectional or more unidirectional

rsync will generally create a new version of a file alongside the destination, and then switch it across to the destination name at the last moment, when it is complete. The new version can be created either using deltas, i.e. changes between the source and destination, or as a full copy. (See my answer for Smarter filetransfers than rsync? for some clarity over this difference.)

The --partial flag tells rsync to keep and use any partially transmitted file as the target if the connection is interrupted for any reason. (Otherwise, a partially transmitted file is discarded.) The advantage of this flag is that time and bandwidth spent transferring a file is not wasted when the rsync is interrupted and retried. The disadvantage of this flag is that a file 90% transferred before interruption can end up being replaced with the same file only 10% transferred before interruption.

The --inplace flag tells rsync to build the destination file directly in place. This is often less efficient in time but avoids having two full copies of the destination file on the remote filesystem simultaneously. In the general case this flag should not be used (and indeed it conflicts with some other options such as --sparse).

When it comes to rsync, think of client and server as roles, that the same rsync binary can fulfill. When it's running as a daemon, you build an rsyncd.conf file, and run rsync with the --daemon argument.

One rsync binary can connect to another (remote) rsync binary either directly - if rsync is running as a daemon listening for it's own connections on a remote host, or via remote shell execution - where rsync uses ssh to connect to a remote host and execute the rsync binary at that host, with both rsync processes passing data back and forth to each other.

To hopefully answer your questions:

1. When transferring files between local and remote by accessing via rsync daemon, is the remote host required to run rsync as a daemon?

   • Yes. If you're going to access an rsync daemon, that daemon has to be running.

2. When transferring files between local and remote by accessing via a remote shell, does the remote host need to run rsync? If yes, does the remote host run rsync as a server but not as a daemon, or just as the local host runs rsync as a client?

   • Yes. When rsync has to be available on both hosts, either in the default $PATH, or with the full path to the binary specified in the command options.

3. When transferring files within the local host, does the local host need to run a rsync client and a rsync server?

   • No. The rsync client binary can function as both roles at the same time if both the SRC and DEST paths are locally available.

4. When listing the source files instead of copying, if the source is in a remote host, does the remote host need to run rsync as a server or daemon?

   • No, running an rsync daemon is not necessary, a remote client can be triggered if you use rsync -e ssh to access rsync (the client) on the remote host. (The remote-shell-spawned rsync in Q 6.)

5. Which use cases does "Note that rsync must be installed on both the source and destination machines" apply to, and not apply to, respectively?

   • The rsync binary must be installed on both machines. In the case that the SRC and DEST are the same machine, the lone rsync binary will essentially perform both roles.

6. In the GENERAL part, "a server can be either a daemon or a remote-shell spawned process". Does a remote host running rsync as a server as "a remote-shell spawned process" mean that the remote host runs rsync in the same way as the local host runs rsync?

   • Yes. Effectively so. The only item of note is that the remotely spawned rsync session is fulfilling the server role.