Coda File System

"Unknown error: 198" during re-integration

From: Peter Schüller <>
Date: Sat, 5 Jul 2003 17:17:58 +0200

While testing disconnected operation I have run into a new problem. When 
issuing a reconnect followed by a checkservers after having made 
modifications in disconnected mode, venus often ("often"? see below)
fails with errors such as:

15:27:55 to /usr/coda/spool/1000/coda.root@_coda.tar
15:27:55 and /usr/coda/spool/1000/coda.root@_coda.cml
15:27:55 Reintegrate: coda.root, 100/544 records, result = Unknown error: 198

After that, no modification will ever be propagated to the server. I have had 
to wipe the local cache (losing all changes) in order to be able to connect 
to the server again.

This happens on both my Linux 2.4.20 system with Coda 5.3.20, and on my 
FreeBSD 4.8 STABLE (cvsup:ed today and built today) with the same version of 
Coda. On Linux it's not even possible to restart Venus because /coda is never 
unmounted, so I have to reboot each time. On FreeBSD I can just restart 
venus, but I still have to wipe the local cache and reinitialize venus in 
order to talk to the server.

With the FreeBSD client after restart, I got messages like the following after 
a while:

15:38:21 volume coda.root has unrepaired local subtree(s), skip checkpointing 
15:43:22 Reintegrate coda.root pending tokens for uid = 1000

The server is running on the FreeBSD machine.

I found a message in the archives where someone describes having a similar 
problem, but no solution.

About "often" above; sometimes it works for a few changes. It usually breaks 
when the changes are up in the hundreds. I've been testing by taking a 
dirctory (around 181 K in size with perhaps a hundred or so files in it) and 
copying it recursively inside Coda. Also tried rm -rf:ing it. In both cases, 
venus usually breaks upon re-integration, but not *always*.  It may be that 
it does always break if I do the exact same thing; so far I have not 
confirmed a case where I did the exact same thing twice and it only breaking 

Note that when it breaks it will flush a few hundred changes successfully 
(looking at the venus log and the output of cfs listvol /coda), but then get 
stuck somewhere with the above errors.

/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <>'
Key retrival: Send an E-Mail to
E-Mail: Web:
Received on 2003-07-05 10:17:32