GNU Info

(remsync.info)Internals

---

Next: Quick start Prev: Overview Up: Overview

---

Enter node , (file) or (file)node

How `remsync' works
===================

   How does `remsync' keep track of what is in sync, and what isn't?
Note: Xremsync, for a the documentation on the `.remsync' file
format.  I understand that a mere description of the format does not
replace an explanation, but in the meantime, you might guess from the
format how the program works.

   All files are summarized by a checksum, computed by the `sum'
program.  There are a few variants of `sum' computing checksums in
incompatible ways, under the control of options.  `remsync' attempts to
retrieve on each site a compatible way to do it, and complains if it
cannot.

   `remsync' does not compare dates or sizes.  Experience shown that the
best version of a file is not necessarily the one with the latest
timestamp.  The best version for a site is the current version on this
site, as decided by its maintainer there, and this is this version that
will be propagated.

   Each site has an idea of the checksum of a file for all other sites.
These checksums are not necessarily identical, for sites do not
necessarily propagate to all others, and the propagation network maybe
incomplete or asymmetrical in various ways.

   Propagation is never done unattended.  The user on a site has to call
`remsync broadcast' to issue synchronization packages for other sites.
If this is never done, the local modifications will never leave the
site.  The user also has to call `remsync process' to apply received
synchronization packages.  Applying a package does not automatically
broadcast it further (maybe this could change?).

   If a site A propagates some files to sites B and D, but not C, site
B is informed that site D also received these files, and site D is
informed that site B also received these files, so they will not
propagate again the same files to one another.  However, both site B
and D are susceptible to propagate further the same files to site C.

   It may happen that a site refuses to update a file, or modifies a
file after having been received, or merges versions, or whatever.  So,
sites may have a wrong opinion of the file contents on other sites.
These differences level down after a few exchanges, and it is very
unlikely that a file would not be propagated when it should have.

   This scheme works only when the various people handling the various
files have confidence in one each other.  If site B modifies a file
after having received it from site A, the file will eventually be
propagated back to site A.  If the original file stayed undisturbed on
site A, that is, if `remsync' proves that site B correctly knew the
checksum of the original file, then the file will be replaced on site A
without any user confirmation.  So, the user on site A has to trust the
changes made by the user on site B.

   If the original file on site A had been modified after having been
sent in a synchronization package, than it is the responsibility of the
user on site A to correctly merge the local modifications with the
modifications observed in the file as received from site B.  This
responsibility is real, since the merged file will later be propagated
to the other sites in an authoritative way.