(Illustration by Gaich Muramatsu)
> 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/Received on 2005-07-07 11:44:42