How does the rsync -u option help syncing two folders?

Question

I want folder source and folder destination to be synced, in which all changes in source are to be reflected to destination.

In this case, I would be using the rsync command like so:

rsync -av --progress --delete "/source/" "/destination"

With a / for source to specify its contents and without / for destination.

Now, do I have to use the -u option in order to the destination to update if source has a newer modified time? Or is -av already enough?

And would I need the -i option at all? Thank you!

-u, --update This forces rsync to skip any files which exist on the destination and have a modified time that is newer than the source file. (If an existing destination file has a modification time equal to the source file’s, it will be updated if the sizes are different.) Note that this does not affect the copying of symlinks or other special files. Also, a difference of file format between the sender and receiver is always considered to be important enough for an update, no matter what date is on the objects. In other words, if the source has a directory where the destination has a file, the transfer would occur regardless of the timestamps. This option is a transfer rule, not an exclude, so it doesn’t affect the data that goes into the file-lists, and thus it doesn’t affect deletions. It just limits the files that the receiver requests to be transferred.

--delete This tells rsync to delete extraneous files from the receiving side (ones that aren’t on the sending side), but only for the directories that are being synchronized. You must have asked rsync to send the whole directory (e.g. "dir" or "dir/") without using a wildcard for the directory’s contents (e.g. "dir/*") since the wildcard is expanded by the shell and rsync thus gets a request to transfer individual files, not the files’ parent directory. Files that are excluded from the transfer are also excluded from being deleted unless you use the --delete-excluded option or mark the rules as only matching on the sending side (see the include/exclude modifiers in the FILTER RULES section). Prior to rsync 2.6.7, this option would have no effect unless --recursive was enabled. Beginning with 2.6.7, deletions will also occur when --dirs (-d) is enabled, but only for directories whose contents are being copied. This option can be dangerous if used incorrectly! It is a very good idea to first try a run using the --dry-run option (-n) to see what files are going to be deleted. If the sending side detects any I/O errors, then the deletion of any files at the destination will be automatically disabled. This is to prevent temporary filesystem failures (such as NFS errors) on the sending side from causing a massive deletion of files on the destination. You can override this with the --ignore-errors option. The --delete option may be combined with one of the --delete-WHEN options without conflict, as well as --delete-excluded. However, if none of the --delete-WHEN options are specified, rsync will choose the --delete-during algorithm when talking to rsync 3.0.0 or newer, and the --delete-before algorithm when talking to an older rsync. See also --delete-delay and --delete-after.

Answer 1

Now, do I have to use the -u option in order to the destination to update if source has a newer modified time?

No, that's already the case. What -u does is to prevent changes happening if the destination is newer. Without -u, such files will be updated to the version on the source (which could be older).

And would I need the -i option at all?

-i (like --progress) doesn't affect the sync behavior, just the output that is displayed. It just shows additional information about each file selected.

Answer 2

You've already got an excellent, accepted answer; this answer serves as an embellishment to that answer:

do I have to use the -u option in order [for]to the destination to update if source has a newer modified time? Or is -av already enough?

The -u option is a bit odd IMHO; odd in the sense that it (apparently) prevents rsync from updating the source file's modification time if it happens to be newer on the source. This can be useful in some situations.

And would I need the -i option at all?

IMO, the -i (aka --itemize-changes) option can be extremely useful in troubleshooting issues/questions that always arise in the use of rsync. One issue with the use of this option is described in man rsync as follows:

... a cryptic output that is 11 letters long. The general format is like the string YXcstpoguax

... with cryptic being the operative word. However, I found the following table which helps a bit. I copy & paste this table as a gigantic # comment into shell scripts that call rsync :

# decode --itemize-changes output:
#
# YXcstpoguax  path/to/file
# |||||||||||
# `----------- "Y" - the type of update being done::
#  ||||||||||   < : file is being transferred to the remote host (sent).
#  ||||||||||   > : file is being transferred to the local host (received).
#  ||||||||||   c: local change/creation for the item, such as:
#  ||||||||||      - the creation of a directory
#  ||||||||||      - the changing of a symlink,
#  ||||||||||      - etc.
#  ||||||||||   h: the item is a hard link to another item (requires --hard-links).
#  ||||||||||   .: the item is not being updated (though it might have attributes that are being modified).
#  ||||||||||   *: means that the rest of the itemized-output area contains a message (e.g. "deleting").
#  ||||||||||
#  `---------- "X" - the file type:
#   |||||||||   f for a file,
#   |||||||||   d for a directory,
#   |||||||||   L for a symlink,
#   |||||||||   D for a device,
#   |||||||||   S for a special file (e.g. named sockets and fifos).
#   |||||||||
#   `--------- c: different checksum (for regular files)
#    ||||||||     changed value (for symlink, device, and special file)
#    `-------- s: Size is different
#     `------- t: Modification time is different; T: time set to transfer time
#      `------ p: Permission are different
#       `----- o: Owner is different
#        `---- g: Group is different
#         `--- u: reserved for future use
#          `-- a: The ACL information changed
#           `- x: extended attribute changed

For example, consider the following output line produced by using the -i option:

>f..t....... Desktop/pics/SomePicture.jpg

Decoded as:

• > : file is being transferred to the local host (received)
• f : a file is being transferred
• t : Modification time is different