I am running coda from cvs.  Last build on 2001-07-17.  I read the
diffs since then and don't see anything relevant.

I put a largish (200k) file into coda while disconnected, and made a
few mistakes, so I ended up naming it wrong and running mv twice.
Here is my CML:

Create  /coda/home/gdt/ELF-4
Chown   /coda/home/gdt/ELF-4 (owner = 0)
Chmod   /coda/home/gdt/ELF-4 (mode = 644)
Store   /coda/home/gdt/ELF-4 (length = 202597)
Rename  /coda/home/gdt/ELF-4 (to: /coda/home/gdt/FreeBSD/ELF-4/bpdksh-5.2.14.tgz)
Rename  /coda/home/gdt/FreeBSD/ELF-4/bpdksh-5.2.14.tgz (to: /coda/home/gdt/FreeBSD/ELF-4/pdksh-5.2.14.tgz)

I don't see why this should be a problem, as ~/ELF-4 doesn't exist,
and there was no file with ksh in the name in the real target
directory.  There are 45 other files there with different names.

When I reconnected (via a local lan hop and then 28.8 dialup), I found

  Status of volume 0x7f000001 (2130706433) named "u.gdt"
  Volume type is ReadWrite
  Connection State is WriteDisconnected
  Minimum quota is 0, maximum quota is unlimited
  Current blocks used are 362613
  The partition has 3208094 blocks available out of 3849596
  Write-back is disabled
  *** There are pending conflicts in this volume ***
  There are 6 CML entries pending for reintegration

Looking in ~/FreeBSD/ELF-4, I found a dangling conflict symlink


gdt gdt 786 ~/%co/FreeBSD/ELF-4 > l pdksh-5.2.14.tgz 
lr--r--r--  1 root  4294967294  27 Aug 15 09:16 pdksh-5.2.14.tgz -> @7f000001.ffffffff.00080011

I would expect this to be a local/global conflict (I only have one server)

Trying to repair, it seems to lose.

gdt gdt 787 ~/%co/FreeBSD/ELF-4 > repair
This repair tool can be used to manually repair server/server 
or local/global conflicts on files and directories. 
You will first need to do a "beginrepair" to start a repair
session where messages about the nature of the conflict and
the commands that should be used to repair the conflict will
be displayed. Help message on individual commands can also be
obtained by using the "help" facility. Finally, you can use the
"endrepair" or "quit" to terminate the current repair session.
repair > begin pdksh-5.2.14.tgz
VIOCGETVOLSTAT /coda/home/gdt/FreeBSD/ELF-4/pdksh-5.2.14.tgz/global failed
Could not allocate replica list
beginrepair failed.
repair > 
[6]+  Stopped                 repair

This is not too surprising, as there is no server state for this file.


gdt gdt 788 ~/%co/FreeBSD/ELF-4 > l pdksh-5.2.14.tgz 
total 198
lrw-r--r--  1 root  nobody      27 Aug 15 08:41 global -> @7f000001.00003796.00003c52
-rw-r--r--  1 root  nobody  202597 Aug 15 07:24 local

Now, repair won't let me discardlocal or replay the cml, since the
repair attempt fails.  I can 'cfs er' to get it back to the original state.

So, any clues as to what is wrong?
Specifically:

Why is this a conflict?

Is venus trying to compress the CML?  Strictly speaking, this is fuzzy
on semantics, since if someone else added a ~/ELF-4 file while I was
disconnected, then this should be a conflict, since my mistake would
have bashed it.

How can there be a conflict but not a conflict?  Note that there is no
conflict in the homedir.

Why can't venus apply the earlier steps of the CML?  Or if not, why
isn't there a conflict in my homedir?



As a minor issue, I am running with the following local patch, to get
around lossage with the 28.8 link where the bw estimate gets too big
and then I get timeouts.

Index: comm.cc
===================================================================
RCS file: /coda-src/coda/coda-src/venus/comm.cc,v
retrieving revision 4.74
diff -u -r4.74 comm.cc
--- comm.cc     2001/05/25 11:48:10     4.74
+++ comm.cc     2001/08/15 13:27:52
@@ -1392,6 +1392,9 @@
         adv_mon.ServerConnectionStrong(name);
     }
 
+    if ( bw > 2000 ) bw = 1999;
+
+
     *Bandwidth = bw;
     if (bw != oldbw) {
        MarinerLog("connection::bandwidth %s %d %d %d\n", name,bwmin,bw,bwmax);

But I'm pretty sure this is orthogonal to the conflict :-)