From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <24ec1936fd3695722aadfd917087bd0f@plan9.escet.urjc.es>
To: 9fans@cse.psu.edu
From: Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: [9fans] replica/sync & change proposal for removed entries
Date: Mon,  3 Jun 2002 16:34:30 +0200
Topicbox-Message-UUID: a49ebd86-eaca-11e9-9e20-41e7f4b1d025

I ended up implementing a new program for replica(8).  It's called
replica/sync and uses the replica dbs directly (without looking at the
logs) to perform what a replica/pull plus a replica/push would do.

My reasons for doing so were:
- I had some problems with replica deleting some files, probably
  due to my ignorance or to hard to see bugs; but all of them seem
  to be related to the use of logs by replica programsⁱ. Thus I wanted
  to avoid logs.

- I tried Tra, but its minisync takes a very long time to sync a (big) home
  directory on my laptop (which is not a fast machine).

- I wanted a simple tool to sync multiple replicas, along the lines of
  other replica(8) programs.

Since bugs in this new tool may harm, I won't distribute it until using
it myself for some more time; if anyone wants the source just drop me
a line.

The proposal I'd like to make is to change a little bit the format
of the REMOVED data base entries in replica.

Currently they are like this

	bin/rc/sync xxx REMOVED xxx xxx 0 0

And I'd like to keep, if possible, the last known mtime for the file
before its removal, like

	bin/rc/sync xxx REMOVED xxx xxx 1022782353 0

replica/sync needs this to work, since otherwise it would be hard to know
whether a file was added at one place or removed at the other.
I already made the change to my local replica(8) and it doesn't seem to
harm other replica tools.

In any case, thanks a lot for adding a nice set of replica tools.

	-N

ⁱ - I'm still trying to find what's the cause of the misterious deletions.
    and will drop a line in case I find it out.