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
58a79f4b
Commit
58a79f4b
authored
Nov 19, 2009
by
Matt McCutchen
Committed by
Wayne Davison
Apr 24, 2010
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Amplify the man page description of --hard-links (see bug 3693), and
improve that of --inplace while I'm at it.
parent
ae03e0e0
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
35 additions
and
20 deletions
+35
-20
rsync.yo
rsync.yo
+35
-20
No files found.
rsync.yo
View file @
58a79f4b
...
@@ -761,17 +761,26 @@ its data needs to be updated: instead of the default method of creating
...
@@ -761,17 +761,26 @@ its data needs to be updated: instead of the default method of creating
a new copy of the file and moving it into place when it is complete, rsync
a new copy of the file and moving it into place when it is complete, rsync
instead writes the updated data directly to the destination file.
instead writes the updated data directly to the destination file.
This has several effects: (1) in-use binaries cannot be updated (either the
This has several effects:
OS will prevent this from happening, or binaries that attempt to swap-in
their data will misbehave or crash), (2) the file's data will be in an
quote(itemization(
inconsistent state during the transfer, (3) a file's data may be left in an
it() Hard links are not broken. This means the new data will be visible
inconsistent state after the transfer if the transfer is interrupted or if
through other hard links to the destination file. Moreover, attempts to
an update fails, (4) a file that does not have write permissions can not be
copy differing source files onto a multiply-linked destination file will
updated, and (5) the efficiency of rsync's delta-transfer algorithm may be
result in a "tug of war" with the destination data changing back and forth.
reduced if some data in the destination file is overwritten before it can
it() In-use binaries cannot be updated (either the OS will prevent this from
be copied to a position later in the file (one exception to this is if you
happening, or binaries that attempt to swap-in their data will misbehave or
combine this option with bf(--backup), since rsync is smart enough to use
crash).
the backup file as the basis file for the transfer).
it() The file's data will be in an inconsistent state during the transfer
and will be left that way if the transfer is interrupted or if an update
fails.
it() A file that does not have write permissions cannot be updated.
it() The efficiency of rsync's delta-transfer algorithm may be reduced if
some data in the destination file is overwritten before it can be copied to
a position later in the file. This does not apply if you use bf(--backup),
since rsync is smart enough to use the backup file as the basis file for the
transfer.
))
WARNING: you should not use this option to update files that are being
WARNING: you should not use this option to update files that are being
accessed by others, so be careful when choosing to use this for a copy.
accessed by others, so be careful when choosing to use this for a copy.
...
@@ -915,17 +924,23 @@ to modify your receiving hierarchy.
...
@@ -915,17 +924,23 @@ to modify your receiving hierarchy.
See also bf(--copy-dirlinks) for an analogous option for the sending side.
See also bf(--copy-dirlinks) for an analogous option for the sending side.
dit(bf(-H, --hard-links)) This tells rsync to look for hard-linked files in
dit(bf(-H, --hard-links)) This tells rsync to look for hard-linked files in
the
transfer and link together the corresponding files on the receiving
the
source and link together the corresponding files on the destination.
side. Without this option, hard-linked files in the transfer
are treated
Without this option, hard-linked files in the source
are treated
as though they were separate files.
as though they were separate files.
When you are updating a non-empty destination, this option only ensures
This option does NOT necessarily ensure that the pattern of hard links on the
that files that are hard-linked together on the source are hard-linked
destination exactly matches that on the source. Cases in which the
together on the destination. It does NOT currently endeavor to break
destination may end up with extra hard links include the following:
already existing hard links on the destination that do not exist between
the source files. Note, however, that if one or more extra-linked files
quote(itemization(
have content changes, they will become unlinked when updated (assuming you
it() If the destination already contains hard links, rsync will not break
are not using the bf(--inplace) option).
them explicitly. However, if one or more of the paths have content
differences, the normal file-update process will break those links, unless
you are using the bf(--inplace) option.
it() If you specify a bf(--link-dest) directory that contains hard links,
rsync may use the same bf(--link-dest) file multiple times via several of
its paths.
))
Note that rsync can only detect hard links between files that are inside
Note that rsync can only detect hard links between files that are inside
the transfer set. If rsync updates a file that has extra hard-link
the transfer set. If rsync updates a file that has extra hard-link
...
...
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