On Tue, Feb 28, 2006 at 11:41:53PM -0600, Jerry Amundson wrote:
> Server1:
> [root_at_aspen amundson.ws]# ll mail/jerry/Maildir/
...
> lr--r--r--  1 root  nfsnobody    29 Feb 28 23:20 tmp -> @7f000001.ffffffff.000819a7_at_amundson.ws

These are conflicts on directories that were created during disconnection. So these are probably local-global (reintegration conflicts).

> Server2:
> ll
> total 5
> drwxrwxrwx  1 root nfsnobody 2048 Oct 21 20:00 docs
> lrw-r--r--  1 1019 nfsnobody    6 Oct 19 07:30 mail -> #mail
> drwxrwxrwx  1 root nfsnobody 2048 Feb 23 23:42 www
> 
> That "#" symlink was the one that threw me off - hadn't seen 
> that before...

That is the mountlink, I guess mail is a separate volume. This is what
you see when the client had a problem reaching the servers where the
volume replicas are stored.

> And another, view of things...
> 
> Client1:
> 
> $ ll mail/jerry/
> total 1
> lr--r--r--  1 root nfsnobody 29 Feb 28 22:42 Maildir -> @7f000001.0000000d.00000004_at_amundson.ws

And that is a server-server conflict. So you have a server-server
conflict on mail/jerry/Maildir, this has probably caused the
reintegration to fail on Server1, it can't actually show the
server-server conflict because it has local dirty state, to show the
conflict it would have to refetch Maildir from the servers, but that
directory is considered dirty on the client because there are CML
records associated with it, so it cannot refetch it.

> Are the "@" symlinks remnants of original local-global conflicts I
> started repairing, and continue repairs the same way?

Probably, but you probably should fix the server-server conflict first
unless you are resolving the reintegration conflict by simply discarding
any local changes.

Jan