I am not quite sure right now, but I remember having tried
nolock using automount, and got log messages indicating
"option not supported" (I have to check tomorrow morning
at work).
Moreover, we are using 'procmail' to redirect mail messages
in home-based folders (ie, NFS folders), and are no longer
using NFS mounted /var/spool/mail directory. We need to have
some kind of locking mechanism for other utilities on our
home NFS directories, so we can not anyway use 'nolock' to
automount them (right ?).
My feeling is that it would be better to fix the locking
approach of mutt. Elm failed to work also with the new 2.2.x
kernels : I did recompile it (it checks which locking method it
can use during its configuration). But I have still one
problem with elm : I tried to recompile elm-ME+ (with MIME
support), and it fails during folder resynchronisation (at
least it did fail with 2.2.0-pre7ac4).
The symptom of the failure are as follows :
MBOX is my NFS folder
TMP is a working copy of MBOX in /tmp
1 fopen(MBOX)
2 unlink(MBOX) : MBOX is still visible (from the Linux box)
3 ftruncate(MBOX)
4 fread(TMP, Buffer) & fwrite(MBOX, Buffer) (<=> copy TMP in MBOX)
Up to now, MBOX is still visible from the Linux box
5 fflush(MBOX)
6 <a few seconds later> : MBOX has disappeared
7 elm-ME+ does not like to have lost MBOX ;-( (and I do not either)
It is working nice with the 2.0.x kernel serie. Maybe a(nother ?)
cache problem with the new NFS layer ?
A+
-- Thierry Danis- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/