Resync of rdiff-backup directories
Mon, 04 Feb 2002 17:02:31 -0800
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001
-----END PGP SIGNATURE-----