On Mon, 17 Feb 2003 15:02:59 -0600 "Christopher R. Hertel" <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 17, 2003 at 02:53:14PM +0100, Olaf Fr?czyk wrote: > > On Mon, 2003-02-17 at 14:42, Ireneusz Piasecki wrote: > > > Hi. > > > > > > I use samba with linux 7.2 kernel 4.7, samba 2.2.1a > > > > > Is there any solution to avoid these errors ?? > > > > > > With redhat 6.2 and samba 2.0.2 (?) tehere were no errors. > > > > > Hi, > > > > I had the same problems. Upgrade your samba to 2.2.7a and it will work > > OK. > > It was fixed about 2.2.6 AFAIK. > > BTW, oplocks are unreliable by definition, so I don't use them. > > The small speed improvement (if any) is not worth loosing data integrity > > from my point of view. > > Um... Just curious, but how are "oplocks are unreliable by definition"? I wondered what was meant by this too. I concluded it was just a zealous choice of words. I believe he means that a) even after being granted an oplock break the client may still find the file is locked and ultimately get a sharing violation and b) on any system other than Windows or systems with kernel oplocks the file can still be written to and possibly c) if the oplock holder looses connectivity and another writer commits changes data will be lost. There's nothing unreliable or technically flawed about the protocol though. NFSv4 will have the same issues. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
