Hans Lermen writes:
> On Mon, 21 Jun 1999, Uwe Bonnes wrote:
>
> > on some lredired drive I only get
> > K:\>pi
> > Zugriff verweigert
> > (this means access denied)
> > I don't know at which knob to turn to fix this behaviour, and haven't
> > found anything in the docs. ^^^^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
Obviously I didn't look hard enough...
> As of doc/README.txt of 0.98.7 and 0.99.12:
>
> 6. Using Lredir
> ...
> 6.1. ..
> ...
> You may even redirect to a NFS mounted volume on a remote machine with
> a /etc/fstab entry like this
>
> otherhost: /dos nfs nolock
>
> Note that the nolock option is needed for 2.2.x kernels, because
> ^^^^^^ ^^^^^^ ^^^^^ ^^^^^^^
> apparently the locks do not propagate fast enough and DOSEMU's (MFS
> code) share emulation will fail (seeing a lock on its own files).
>
> >
> > K: is my home directory, which is NFS mounted.
> ^^^^^^^^^^^
> Yup, and you for sure have a 2.2.x kernel, right? ;-)
>
> You don't have that problem with 2.0.x because it ignores locks silently.
> I got a patch for mfs.c to ignore locks on 2.2.x too, maybe I'll aply it
> in the next releases. However, he caveat of this would be that the fact
> fact that files on a 2.2.x mounted volume aren't locked is hidden.
> This makes a difference now NFS _is_ locking (on 2.0.x every body knew
> that it wasn't).
>
That's it.
Shouldn't the MFS code check for the error code and in case of the
failing lock wait some moments and then try again before failure?
What's the implication of "nolock" on my home drive.
man 8 mount is quite short on nolock:
"nolock Do not use locking. Do not start lockd."
Thanks
Uwe Bonnes [EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
