On Fri, Aug 13, 1999 at 02:37:16PM -0500, Bill Gribble wrote:
> There's a process on the slow client creating log files (in a Coda
> volume served by a third machine on the fast network) that are to be
> analyzed by a process on the fast client.
> 
> Everybody's clocks are synced by xntp. 
> 
> I ran my codes and found that the log files were never appearing on
> the fast client (or, more precisely, appeared but were empty), even
> though the slow client issued a 'cfs strong'. 

Hi Bill,

Yup, that is a sometimes unexpected `feature' of the way Coda guarantees
consistency of the filedata. As long as the (syslog?) daemon keeps the
files open for writing, Coda assumes that the file is still in a state
of inconsistency (being updated). The file will be sent as soon as the
last writer closes it,. except if you are weakly connected, then it will
take about 5 minutes longer. You can rotate the logs every once in a
while to `flush' them to the servers.

You see the empty file on the other machine, because the "create"
operation was already sent back to the servers.

Also you will not be able to easily `outsmart' the logic in venus by
closing and opening the file between each write call. That stops working
as soon as venus starts logging, then it uses the open-for-writing state
of the file as an indication to optimize the pending stores out of the
log.

The best solution is to write the logs to local disk (/var/spool/...),
and rotate them into /coda. Then your logger/application won't get stuck
when the volume becomes read-only due to a conflict.

> Thanks for any advice,
> Bill Gribble

Jan