On Thu, Sep 21, 2000 at 04:57:37PM +0200, Piotr K. Isajew wrote:
> I'm using coda on one machine running FreeBSD whitch is both server
> and client. A few days ago I put my mailbox (qmail's Maildir/ format)
> on a coda volume.
The qmail definition for maildir is as far as Coda is concerned a little
bit broken. The `nfs-safe' renames are defined as creating a
cross-directory link, and if that succeeds, removing the source.
However, Coda doesn't support cross-directory linking.
Mutt already incorporated a patch we sent them which makes the nfs-safe
renames work correctly in a Coda filesystem. It looks something like the
following,
int nfs_safe_rename(srcpath, destpath)
{
int err;
err = link(srcpath, destpath);
+ if (err == -1 && errno == EXDEV)
+ return rename(srcpath, destpath);
if (err == -1)
return err;
return unlink(srcpath);
}
> Since then there are several problems (not connected with qmail).
>
> Each process whitch tries to access /coda directory hangs on
> "coda_call". Sometimes I can manage to interrupt such a process with
> "Ctrl+C", and then I see something like this:
Do you have everything in the same volume? Coda locks on a per volume
basis, and some weird problem in the tree can now potentially lock
access to everything.
Is venus running? Can you turn up venus debugging (vutil -d 10) and see
if the client is actually trying to service the kernel's upcalls?
Jan
