On Tue, Apr 03, 2001 at 10:32:37PM +0200, Clemens Hermann wrote:
> Hi,
> 
> as the FAQ does not give a final answer I would appreciate it a lot to get a
> quick statement here. I thought of coda to make some mail-replication but I
> am not sure if coda can solve the problem and if coda should be used in this
> situation.
> 
> Two computers are connected from time to time via ISDN and share a
> directory. On Computer A files can be deleted and created. on Computer B
> files can only be deleted. I want to "mirror" the directory. If on either
> one of the computers a file gets deleted, it must be automatically deleted
> on the other one during the next replication. If a file is created on
> machine A, it must be coppied to machine B during replication.
> Files will not be modified, just be created and deleted.

Are you writing your own mailsystem? All systems that I know of are
doing a lot more than just creating/deleting. Status flags (read/replied) 
tend to be stored inside the file, except for maildir, where the file is
renamed.

> So now:
> - can Coda solve the problem?

Maybe, the Coda server and one client would be located at machine A,
while machine B would only run a client. Coda might give some nasty
surprises, since it uses very strict consitency checking when machine B
is reintegrating, f.i. when the file is deleted at both sides it is
considered a 'conflict', the reintegration is frozen and the directory
is turned into a dangling symlink until the user repairs the conflict.

> - is coda ready for this situation?`

Don't know, I expect that your application will be doing more
interesting things than just creating and deleting (f.i. renaming across
directories when it is maildir format, or modifying the file contents
when it is MH).

> - are there any security-considerations (the server should stay secure ;-)?

Coda effectively doesn't have encryption implemented, only a rudimentary
encoding scheme to 'prove' encryption is possible. However, real
encryption is sufficiently different that it isn't really plug-n-play to
add it into the system. So that is always a consideration.

> - Is there a better way to solve the problem?

Maybe an imap/pop + fetchmail solution. Or unison might work, although
that one could get confused by biff like mailcheckers that play around
with the file ctime/mtime/atime. Rsync probably wouldn't work in this
case, as it wouldn't be able to distinguish between a file that was
deleted on machine B and a file that was newly created on machine A.

    unison: http://www.cis.upenn.edu/~bcpierce/unison/

Jan