Attachment 4964 Details for Bug 3693 – Updated man page patch

[patch] Updated man page patch

hard-links-man.patch (text/plain), 4.56 KB, created by Matt McCutchen on 2009-11-18 23:31:17 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Matt McCutchen

Created: 2009-11-18 23:31:17 UTC

Size: 4.56 KB

patch

obsolete

>From e2f07f9f390bd73c173e6e065d4a9a78fb962f9f Mon Sep 17 00:00:00 2001
>From: Matt McCutchen <matt@mattmccutchen.net>
>Date: Thu, 19 Nov 2009 00:18:23 -0500
>Subject: [PATCH] Amplify the man page description of --hard-links (see bug 3693), and
> improve that of --inplace while I'm at it.
>
>---
> rsync.yo |   55 +++++++++++++++++++++++++++++++++++--------------------
> 1 files changed, 35 insertions(+), 20 deletions(-)
>
>diff --git a/rsync.yo b/rsync.yo
>index 103538a..034e88b 100644
>--- a/rsync.yo
>+++ b/rsync.yo
>@@ -763,17 +763,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
> instead writes the updated data directly to the destination file.
> 
>-This has several effects: (1) in-use binaries cannot be updated (either the
>-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
>-inconsistent state during the transfer, (3) a file's data may be left in an
>-inconsistent state after the transfer if the transfer is interrupted or if
>-an update fails, (4) a file that does not have write permissions can not be
>-updated, and (5) 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 (one exception to this is if you
>-combine this option with bf(--backup), since rsync is smart enough to use
>-the backup file as the basis file for the transfer).
>+This has several effects:
>+
>+quote(itemization(
>+  it() Hard links are not broken.  This means the new data will be visible
>+  through other hard links to the destination file.  Moreover, attempts to
>+  copy differing source files onto a multiply-linked destination file will
>+  result in a "tug of war" with the destination data changing back and forth.
>+  it() In-use binaries cannot be updated (either the OS will prevent this from
>+  happening, or binaries that attempt to swap-in their data will misbehave or
>+  crash).
>+  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
> accessed by others, so be careful when choosing to use this for a copy.
>@@ -917,17 +926,23 @@ to modify your receiving hierarchy.
> 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
>-the transfer and link together the corresponding files on the receiving
>-side.  Without this option, hard-linked files in the transfer are treated
>+the source and link together the corresponding files on the destination.
>+Without this option, hard-linked files in the source are treated
> as though they were separate files.
> 
>-When you are updating a non-empty destination, this option only ensures
>-that files that are hard-linked together on the source are hard-linked
>-together on the destination.  It does NOT currently endeavor to break
>-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
>-have content changes, they will become unlinked when updated (assuming you
>-are not using the bf(--inplace) option).
>+This option does NOT necessarily ensure that the pattern of hard links on the
>+destination exactly matches that on the source.  Cases in which the
>+destination may end up with extra hard links include the following:
>+
>+quote(itemization(
>+  it() If the destination already contains hard links, rsync will not break
>+  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
> the transfer set.  If rsync updates a file that has extra hard-link
>-- 
>1.6.5.3.154.gbd911
>

Actions: View

Attachments on bug 3693: 3129 | 4964