> I would guess there is a directory that has exceeded the 256KB limit.

	That would make sense, except that it doesn't seem to be the case.
First of all, we've copied this exact file structure into coda before
without problem.  Second, there aren't many files in this directory or
the parent.  Here's a terminal session that shows the problems.  The
file sources were in /root/pool_scm and being copied
to /coda/director/snapin/pool_scm:

# venus -init
# cfs flushcache
# cd /coda/director/snapin/pool_scm
# ls
a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  q  r  s  t  u  v  w  x
y  z
# ls /root/pool_scm
a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  q  r  s  t  u  v  w  x
y  z
# ls /root/pool_scm/r
readline2.2.1-2.2.1-4.i386.rpm
rpm-4.0.4-7x.20.i386.rpm
readline-4.2-2.i386.rpm
rsh-0.17-18.AS21.2.i386.rpm
restore-default-system-1.0-20031001.i386.rpm
rsh-0.17-18.AS21.4.i686.rpm
rootfiles-7.2-1.noarch.rpm
# du -s -h /root/pool_scm/r
2.6M    /root/pool_scm/r
# ls r
ls: r/readline-4.2-2.i386.rpm: No such device

	At this point, venus has crashed.  The console.log file has the
erroneous seeming errors that I pasted before, but to show again:

***LWP (0x810ec50): Select returns error: 4

09:28:28 worker::main Got a bogus opcode 36
09:29:30 readline-4.2-2.i386.rpm (606e1fc8.7f000003.1018.4de)
inconsistent!
09:29:30 fatal error -- fsobj::dir_Create: (dir225,
606e1fc8.7f000003.fffffffc.80002) Create failed!
09:29:30 RecovTerminate: dirty shutdown (1 uncommitted transactions)
Assertion failed: 0, file
"/home/pwalsh/working/coda/BUILD/coda-6.0.11/coda-src/venus/fso_dir.cc",
line 95
Sleeping forever.  You may use gdb to attach to process 18895.

	So if readline*.rpm is inconsistent, then that's fine.  If coda is
trying to create a directory automatically for resolution, then that's
fine and makes sense too.  But as to why it is crashing there, I have no
idea.

> Because of the vnode number (fffffffc), it is an automatically created
> fake file identifier, which is probably created as a result of the
> inconsistency. Maybe it is trying to add a dangling symlink object in
...
> This pushed the parent directory over the 256KB limit and dir_Create
> failed, triggering an assertion.

	Doesn't seem as though we should be anywhere near the 256kb limit...

> > 	Question 1: is there any way to get rid of this file of death so we can
> > salvage this installation?
> 
> Reinitializing the client would get rid of the CML so it won't try to
> reintegrate and get rid of the 'local-global' part of the conflict.

	I should have mentioned that I already tried this.  And as you can see
from the above terminal transcript, it had little effect.

	Any other thoughts?

-- 
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/