Resync of rdiff-backup directories

[Ben Escoto]

--==_Exmh_-1838337079P
Content-Type: text/plain; charset=us-ascii

>>>>> "JP" == Jason Piterak <Jason>
>>>>> wrote the following on Mon, 4 Feb 2002 16:55:41 -0500

  JP> Hi Ben, Some nice changes the last few revs (especially like the
  JP> restore from remote server). Hope everything is going well. Had
  JP> another idea for you...

  JP> 1) Create a --force-resync option: One of the great reasons for
  JP> using rdiff-backup is to do backups of remote machines across
  JP> slow links. The problem is that the FIRST rdiff-backup of the
  JP> data requires a complete copy of all data to the remote
  JP> location, something that may not be feasible, depending on the
  JP> speed of the WAN link.
    ...
  JP>   So... To simplify this process, how about an option to resync
  JP> two directories (eg: --force-resync)?

    Have you actually tried the current --force option and it is too
slow?  It doesn't exactly make a "complete copy" each time.
rdiff-backup tries to ensure that the destination is a complete copy
of the source, but it goes about it in an rsync-like way.  So files
that are already identical won't be copied over, and if a file is only
slightly different, only the differences will be transmitted.  It can
also process multiple files per packet for reasonable high latency
performance.  Rsync is going to be faster, but rdiff-backup does a lot
of the same things.

    So anyway I'm hoping that the current system is reasonable fast at
mirroring two directories that are already the same anyway.

  JP> ---------------- Also... How goes the multi-source programming? 
  JP> Any word on how you plan to implement? Some ideas...  Source:
  JP> accept file list from stdin, from file --> from FIFO Filters:
  JP> Allow per-source --include and --exclude filters, with perl
  JP> regex syntax

Sorry, what do you mean multi-source programming?  About accepting a
file list from stdin, I did a fair amount of work on rdiff-backup over
the weekend, but right now I am concentrating on error-recovery.  For
instance, it dumps its state every once in a while, so failed sessions
can be resumed where they left off...

    Acceping the file list from stdin really complicates stuff like
this (resuming is much harder under these circumstances), so I'm going
to put that stuff off until at least 0.5.1.

    What do you mean "from FIFO"?

  JP>   With regards to your note in the man page on quoting the '\',
  JP> something that may or may not be useful (from the Python re
  JP> library notes):

  JP> Regular expressions use the backslash character ("\") to
  JP> indicate special forms or to allow special characters to be used
  JP> without invoking their special meaning. This collides with
  JP> Python's usage of the same character for the same purpose in
  JP> string literals; for example, to match a literal backslash, one
  JP> might have to write '\\\\' as the pattern string, because the
  JP> regular expression must be "\\", and each backslash must be
  JP> expressed as "\\" inside a regular Python string literal.

  JP> The solution is to use Python's raw string notation for regular
  JP> expression patterns; backslashes are not handled in any special
  JP> way in a string literal prefixed with "r". So r"\n" is a
  JP> two-character string containing "\" and "n", while "\n" is a
  JP> one-character string containing a newline. Usually patterns will
  JP> be expressed in Python code using this raw string notation.

Yep, but I think the problem here is the shell and not rdiff-backup.
Any regular expression supplied by the user is not expressed literally
in python, so the r"\n" vs "\n" questions are not apropos.  For
instance, consider these two cases:

1.  I want to match \n as in the character \ followed by character n.
2.  I want to match a newline.

To distinguish these cases, rdiff-backup needs to get the string \\n
for the first case and the string \n for the second.  This is as
simple as it could be, I think.  However, in order to give
rdiff-backup the string \\n, you'll need to type \\\\n into your
shell, because if you just typed in \\n your shell would only give
rdiff-backup \n.

    Or you could use single quotes:  Under bash '\\n' will match case
1 without extraneous backslashes (just like python's r"..." notation).
But csh will bring '\\n' to \n as if the quotes weren't there, so that
solution isn't universal.


--
Ben Escoto

--==_Exmh_-1838337079P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001

iD8DBQE8Xy8j+owuOvknOnURApopAJ42yXL3CCaEVJ2EHsd7G+vT+T08owCePvzL
x8dzjwVFf3dxmoswf/5Vlfw=
=Cwzn
-----END PGP SIGNATURE-----

--==_Exmh_-1838337079P--