On Thu, Aug 07, 2003 at 10:27:34AM -0700, Tim Hasson wrote:
> Sorry for not cc'ing codalist_at_coda.cs.cmu.edu, and i didn't save it either, 
> hope Jan can Fwd the codalist.

I just 'bounced' your email off to codalist.

> I am not only having problems with the courier-imap component only, but also 
> the courier pop3 daemon. Mail users getting the error message "Sorry cannot 
> find the message it's gone".

Hmm, that is unusual. Maybe we're somehow failing to fetch it and return
ETIMEDOUT. The only way to tell would probably be to strace the pop3d
while it is going wrong. But the strace will probably influence the
process enough that the problem might not happen.

> I am having a problem repairing/removeinc'ing my Maildir/tmp after it
> went it consistent. Coda 6.0.2 server, 5.3.20 client, FreeBSD 4.8.
> Replicated volume on 2 servers. One thing is driving me crazy is that
> in the logs I cannot find the path to the inconsistent directory so I
> have to manually dig for it. The log is like:
> 09:26:25 tmp (7f000007.16ff.29eb) inconsistent!

Yeah, I don't like that too much either, but I consider having to go to
the log a bad thing in the first place.

I typically just end up doing "find . -noleaf -lname '@*'", often as
part of a little bash script,

    for conf in `find . -noleaf -lname '@*'` ; do
	repair $conf /tmp/fix -owner 7768 -mode 755
    done

This ofcourse only works reliably for server-server directory conflicts,
which are luckily the most common.

> coda1# repair
...
> repair > compare /dev/null
> The fix file may be empty but ....
> You still need a dorepair because the Version state is different
> repair > dorepair
> Pathname of fixfile? [/dev/null]:

Ahh, that is your problem. Even an empty repair file, will still contain
some information, such as which hosts are involved in the conflict.

The fix-file that you're sending is completely empty, so the servers
can't parse it.

Jan