I felt certain there was an option to do this, but I cannot find it.
I want to rsync a directory on machine A over to machine B, and then rsync
the directory on machine B back to machine A.
The idea is this: I read my email using mutt, which is set to save my
email in ~/Mail in maildir format. This means that each message is in its
own file, instead of being appended to an existing file. Thus, if I backup
my email by rsync'ing it to another machine, only the new messages are
copied
over. Mailboxes need not be. Before you say that rsync only sends changed
blocks, and the changed blocks are at the end if the message is appended,
remember that mail readers write status into the headers of the messages.
If I change the status on the first message in the box (reply to it, delete
it), then the ENTIRE mailbox is re-copied. Not so in maildir format.
Well, I read my email on my laptop, and it is sometimes necessary to
login to a central server to read my email (firewall issues). What I do is
to peridocally sync with the central server (which we'll call
"server") by:
rsync -e ssh -rptlv Mail server:.
rsync -e ssh -rptlv server:Mail .
I'd like to do this in one command. Is there a switch to rsync that
says to make the local and remote directories identical, even if that means
transfering data in both directions?
--
"There is no parameter that makes it impossible Jack McKinney
for you to perform still more excellently." jackmc@lorentz.com
-Mario Cuomo, on the lack of a clock in baseball http://www.lorentz.com
1024D/FBED2DAA 4096g/3F93879F
2002 Chicago Cubs magic number: 163
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20020204/dd8663e8/attachment.bin
On Mon, Feb 04, 2002 at 11:58:04AM -0600, Jack McKinney wrote:> I felt certain there was an option to do this, but I cannot find it. > I want to rsync a directory on machine A over to machine B, and then rsync > the directory on machine B back to machine A. > The idea is this: I read my email using mutt, which is set to save my > email in ~/Mail in maildir format. This means that each message is in its > own file, instead of being appended to an existing file. Thus, if I backup > my email by rsync'ing it to another machine, only the new messages are copied > over. Mailboxes need not be. Before you say that rsync only sends changed > blocks, and the changed blocks are at the end if the message is appended, > remember that mail readers write status into the headers of the messages. > If I change the status on the first message in the box (reply to it, delete > it), then the ENTIRE mailbox is re-copied. Not so in maildir format.Are you sure about that? Rsync is able to locate identical blocks that are in a different position.> Well, I read my email on my laptop, and it is sometimes necessary to > login to a central server to read my email (firewall issues). What I do is > to peridocally sync with the central server (which we'll call "server") by: > > rsync -e ssh -rptlv Mail server:. > rsync -e ssh -rptlv server:Mail . > > I'd like to do this in one command. Is there a switch to rsync that > says to make the local and remote directories identical, even if that means > transfering data in both directions?No there isn't. What's wrong with doing it in two commands? You may be interested in http://mailsync.sourceforge.net which is explicitly designed to sync mailboxes. - Dave Dykstra
There's no such option. Rember that Rsync was devised as an efficient way
to mirror ftp sites. What you're looking for is unison. Some of the guys
on here use it. It's at
"http://www.cis.upenn.edu/~bcpierce/unison", and
looks promising for your application.
Tim Conway
tim.conway@philips.com
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me.... Tim?"
"Jack McKinney" <jackmc-rsync@lorentz.com>
Sent by: rsync-admin@lists.samba.org
02/04/2002 10:58 AM
To: rsync@lists.samba.org
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject: rsync dir in _both_ directions?
Classification:
I felt certain there was an option to do this, but I cannot find it.
I want to rsync a directory on machine A over to machine B, and then rsync
the directory on machine B back to machine A.
The idea is this: I read my email using mutt, which is set to save my
email in ~/Mail in maildir format. This means that each message is in its
own file, instead of being appended to an existing file. Thus, if I
backup
my email by rsync'ing it to another machine, only the new messages are
copied
over. Mailboxes need not be. Before you say that rsync only sends changed
blocks, and the changed blocks are at the end if the message is appended,
remember that mail readers write status into the headers of the messages.
If I change the status on the first message in the box (reply to it,
delete
it), then the ENTIRE mailbox is re-copied. Not so in maildir format.
Well, I read my email on my laptop, and it is sometimes necessary to
login to a central server to read my email (firewall issues). What I do
is
to peridocally sync with the central server (which we'll call
"server")
by:
rsync -e ssh -rptlv Mail server:.
rsync -e ssh -rptlv server:Mail .
I'd like to do this in one command. Is there a switch to rsync that
says to make the local and remote directories identical, even if that
means
transfering data in both directions?
--
"There is no parameter that makes it impossible Jack McKinney
for you to perform still more excellently." jackmc@lorentz.com
-Mario Cuomo, on the lack of a clock in baseball http://www.lorentz.com
1024D/FBED2DAA 4096g/3F93879F
2002 Chicago Cubs magic number: 163
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attj7zff.dat
Type: application/octet-stream
Size: 247 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20020205/44d03c88/attj7zff.obj
On 4 Feb 2002, Jack McKinney <jackmc-rsync@lorentz.com> wrote:> Well, I read my email on my laptop, and it is sometimes necessary to > login to a central server to read my email (firewall issues). What I do is > to peridocally sync with the central server (which we'll call "server") by: > > rsync -e ssh -rptlv Mail server:. > rsync -e ssh -rptlv server:Mail .I think the problem is not so much that it takes two commands, but rather that there is domain-specific merge knowledge that rsync does not have. With your commands, all messages will end up on both machines, which is fine to start with. But if you delete a message it will presumably keep on being copied back from the other machine. I don't know a good way for rsync to distinguish between the case of a message deleted on machine A, and a message newly added on machine B. If you use --update, and only flag files rather than deleting them then I guess you would be OK. -- Martin
Jack McKinney [jackmc-rsync@lorentz.com] writes:> If I add 512 bytes at the begining of the file, then I would expect > it. If I only add 14 bytes, then I don't think rsync will detect this, > as it would require it to compute checksums start at EVERY byte instead > of 512 byte checksums at offsets 0, 512, 1024, 1536, et al.Yep, and that's precisely what rsync does. It actually uses two types of checksums. One is a fast rolling checksum that can be efficiently computed with a block starting at _every_ byte in the file. The nature of the checksum is that you can compute its new value starting at byte X+1, based on its old value from a block starting at X by only performing a single computation based on the new byte at the end of the block starting at X+1. But the penalty you pay for the speed is that it's a "weaker" checksum - you can have inaccurately identified matches (e.g., overlaps in the checksum). So there's a second, much stronger checksum, but much slower, that is used to validate a match once the first checksum thinks it found a match. When you transmit a file, the sender computes both checksums for each block in the file it has and sends them over. The receiver then walks its current file, taking block size chunks _at every byte_ and computing the weak/fast checksum. If the weak matches, it then does the stronger checksum, and if that matches, it knows it need not request that block of data from the sender. This will match common blocks located anywhere within the file at any offset (including re-using a source block multiple times to reproduce the target). You might want to read the tech paper on rsync and its protocol, since it goes into this in much more detail. If all rsync did was match on finite block boundaries, it would be _way_ less useful than it really is.> It is an easy experiment. (...) > (...) I suspect that your xfer time will be comparable to > the first one, not to the second.Since it's an easy experiment - why "suspect" - did you try this? It should take virtually no time for the second (sans the initial checksum computation and transmission, which to be fair for large files and small block sizes can be quite significant). -- David /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/