On Thu, Apr 17, 2003 at 02:26:33PM -0400, Matthias Halfmann wrote:
> have been unable to find a good solution for my current problem. It seem
> so matter what I do when I start populating my volume with data I develop
> local inconsistent objects. Assuming I star rsyncing directory A the

Yeah, rsync can be a pain in the ass. I use it to sync the mailinglist
archives into /coda after a rebuild. It messes up at least once a month,
but when there is sufficient email going to codalist, more often.

As it is a simple one-way rsync, you would expect it to be pretty
straightforward. But rsync both reads the old copy of the file, while
writing out the new version to a temporary file and then renames the
temporary file over the old.

Recently rsync seems to have changed it's strategy slightly. And from
what I can see, instead of creating the temporary copy in the same
directory as the file we're about to overwrite, it creates the temporary
file in the top-level directory of the tree we're syncing to. This
wouldn't be a problem except for the fact that cross directory renames
are not too reliable. If you create a new object and move it to another
directory, you pretty much have to resolve the source directory before
resolving the destination otherwise the 'object' doesn't exist on all
replicas and the server declares a conflict.

Ofcourse this only hits me, as I have replicated servers. There are also
some issues with singly replicated servers that I found after 5.3.20 was
released. This one in particular is probably the cause of your immediate
problems,

http://www.coda.cs.cmu.edu/cgi-bin/viewcvs.cgi/coda/coda-src/vice/codaproc2.cc.diff?r1=4.50&r2=4.51

But I've still got occasional conflicts during rsyncs, so I definitely
have not yet been able to fix everything. If everyone sends more email
to codalist, it will cause more mailarchive rebuilds and I get more of
these conflicts. Perhaps that will push this higher up in the list of
things that really need to be looked at.

Jan