Hello Jan,

thanks for the explanation, appreciated.

On Thu, Feb 28, 2008 at 04:01:29PM -0500, Jan Harkes wrote:
> > Isn't the create operation present in the server volume modification logs
> > which they are to exchange? (You don't have to explain resolution
> > once again here - unless you feel inclined so. I'll go and read elsewhere).
> 
> No problem, resolution happens in several steps and the first one is to
> lock the object. After the store we trigger resolution on the file and
> the server tries to lock it on all replicas. But the "disconnected"
> server has never heard of the object so it fails and we declare a
> conflict.

Ah I see now. Missed the locking step. So basically we should begin
with resolution of the parent directory.

> The logs really only come into play for directory resolution. Assume we
> didn't have the store conflict, but just some file/directory/symlink
> created on only one replica. Then at some later point a client notices
> that the directory versions are different between replicas and triggers

In the original scenario, the client who created an entry before
doing the store knows that the directory has been modified (or may have been
modified? don't know whether "create" always implies modification). Couldn't it
trigger the directory resolution? That is, not only "store, resolve file",
but also "create, resolve parent"?

> When the servers hit the locking issue because one replica is missing
> they should probably recurse up to the parent directory and try to
> resolve that first. That is what we do in most other situations for
> instance when we have a problem resolving a rename.

That looks like a solution, but I am still curious whether we have to
detect such situations or can avoid them altogether by "previous knowledge"
of directory updates?

Regards,
Rune