Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
L
liblongpath-rsync
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
liblongpath
liblongpath-rsync
Commits
c64ff141
Commit
c64ff141
authored
Apr 12, 2007
by
Wayne Davison
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Improved the description of the --checksum option.
parent
1b896f8d
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
20 additions
and
14 deletions
+20
-14
rsync.yo
rsync.yo
+20
-14
No files found.
rsync.yo
View file @
c64ff141
...
...
@@ -488,20 +488,26 @@ transferring to or from an MS Windows FAT filesystem (which represents
times with a 2-second resolution), bf(--modify-window=1) is useful
(allowing times to differ by up to 1 second).
dit(bf(-c, --checksum)) This forces the sender to checksum em(every)
regular file using a 128-bit MD4 checksum. It does this during the initial
file-system scan as it builds the list of all available files. The receiver
then checksums its version of each file (if it exists and it has the same
size as its sender-side counterpart) in order to decide which files need to
be updated: files with either a changed size or a changed checksum are
selected for transfer. Since this whole-file checksumming of all files on
both sides of the connection occurs in addition to the automatic checksum
verifications that occur during a file's transfer, this option can be quite
slow.
Note that rsync always verifies that each em(transferred) file was correctly
reconstructed on the receiving side by checking its whole-file checksum, but
that automatic after-the-transfer verification has nothing to do with this
dit(bf(-c, --checksum)) This changes the way rsync checks if the files have
been changed and are in need of a transfer. Without this option, rsync
uses a "quick check" that (by default) checks if each file's size and time
of last modification match between the sender and receiver. This option
changes this to compare a 128-bit MD4 checksum for each file that has a
matching size. Generating the checksums means that both sides will expend
a lot of disk I/O reading all the data in the files in the transfer (and
this is prior to any reading that will be done to transfer changed files),
so this can slow things down significantly.
The sending side generates its checksums while it is doing the file-system
scan that builds the list of the available files. The receiver generates
its checksums when it is scanning for changed files, and will checksum any
file that has the same size as the corresponding sender's file: files with
either a changed size or a changed checksum are selected for transfer.
Note that rsync always verifies that each em(transferred) file was
correctly reconstructed on the receiving side by checking a whole-file
checksum that is generated when as the file is transferred, but that
automatic after-the-transfer verification has nothing to do with this
option's before-the-transfer "Does this file need to be updated?" check.
dit(bf(-a, --archive)) This is equivalent to bf(-rlptgoD). It is a quick
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment