In article <[EMAIL PROTECTED]>, Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > >On Thu, 26 Aug 1999, Roland Rosenfeld wrote: > >> The solution for this problem is to use fcntl(), because Linux 2.2.* >> flushes the cache of a file in the moment when it is locked using >> fcntl(). >> >> But only fcntl() locking is not enough, because Linux 2.0.* doesn't >> support this over NFS and then we have no locking over NFS. > >And linux 2.2.x with a userland server also does not support fcntl >locking, it generates an annoying kernel message and fails with ENOLCK.
As I said that's because you have to mount the partition with the "nolock" option if the NFS server doesn't support server-side locking. But the problem was that: a) it's hard for liblockfile to use fcntl() locking since it doesn't open the file you want to lock, and the current API doesn't allow you to pass a filehandle. Opening the file anyway and keeping it in some internal state/list would be possible but ugly b) The 2.2.x kernels have a bug that prevents fcntl() from revalidating the cache if you mount wth "nolock", bugger since that is the entire point of calling fcntl() Roland posted a patch from Olaf Kirch that will fix this. I just sent that patch to the linux-kernel mailing list and Alan Cox for possible inclusion into 2.2.13 (I'll try hard to convince Alan to put it in). Now, for point a). I don't think it is mandatory that we actually _use_ fcntl locking - the only thing we want to make sure of is that the cache gets flushed, right? So that after the lock, the attributes of the locked file are up-to-date. I read the kernel source code and found out that the cache gets invalidated *anyway* regardless of the fact that the lock succeeds or not. So, it would be enough to simply open the file-to-be-locked (if it exists already), do an fcntl(F_SETLK) on it, if that succeeds we immediately unlock it, then we close the file. We didn't actually _use_ the lock, but the cache got invalidated regardless. This would let us keep the current policy, and current way to lock the mailspool, but it would fix the problem. Comments? BTW, the original problem was with mutt, right? I don't think mutt actually uses liblockfile - perhaps the mutt maintainer wants to send this message upstream to the mutt developers for informational purposes. Mike. -- ... somehow I have a feeling the hurting hasn't even begun yet -- Bill, "The Terrible Thunderlizards"