[Samba] RE: [Samba]DOS app won't run off a Samba drive!

[Greg Conway]

Again, many thanks - I will be implementing this on my client's four
networked app's tomorrow morning!

Regards,

Greg.

> -----Original Message-----
> From: Rashkae [mailto:rashkae at wealthmap.ca]
> Sent: 30 January 2002 03:04
> To: Greg Conway
> Cc: Nelson, John P.; Samba
> Subject: Re: [Samba] RE: [Samba]DOS app won't run off a Samba drive!
>
>
> Just something to keep in mind Greg.
>
> disabling kernel oplocks disables the linux kernel's ability to share
> locking with Samba, but Samba is still granting oplocks. There is an
> oplocks option (Share level option) that can be used to disable oplocks
> entirely for a given share. This would be a good idea for shares that
> primarily serve database files for multiple users.
>
> oplocks=no
>
> ____________________________________________
> Jan 29  10:01pm
>                        _
> ASCII ribbon campaign ( )
>  - against HTML email  X
>              & vcards / \
>
>
> On Wed, 30 Jan 2002, Greg Conway wrote:
>
> Hi John,
>
> Thanks for the comments, but the original problem was entirely to do with
> Win2K and Win98!
>
> I have a Linux Samba Server that provides network drives to a small LAN.
>
> The client already had three networked DOS apps running off this Samba
> Server.
>
> I added a fourth, and a problem reared it's ugly head.... One single user
> could access the net app, but when a second tried to log in, the Windows
> client froze for about 30 secs, then returned "Unknown disc error on drive
> X", and the app bombed out.
>
> Thanks to this group, I've solved the problem within twelve hours of my
> original posting! For which I am most grateful.
>
> For all those that missed it, adding the line 'kernel oplocks = no' fixed
> it.
>
> But your input is also very welcomed, thanks!
>
> Regards,
>
> Greg.
>
> > -----Original Message-----
> > From: Nelson, John P. [mailto:john.nelson at teradyne.com]
> > Sent: 29 January 2002 18:52
> > To: 'greg at gmlnt.com'
> > Subject: Re: [Samba]DOS app won't run off a Samba drive!
> >
> >
> > >Hi Rashkae,
> >
> > You sent this to the list, so I assume you don't mind someone
> else poking
> > their nose in.
> >
> > I didn't see the original question (I just can't keep up with the
> > volume on
> > the Samba list).  From the subject line, I think I know the
> > problem.  There
> > is a bug in Win9x with long directory names in a network share.
> > If you try
> > to run a DOS program from a directory that contains "long"
> directory name
> > components (more than 8.3 filenames), it will not run properly.
> > This is not
> > specific to Samba - it behaves the same way if the files reside on an
> > NT/Win2k server (with the same pathname).  The bug is in Win9X itself.
> >
> > I used to know what the failure mechanism was, but I forget now.
> > But if you
> > eliminate any "long" pathname components, it doesn't happen.  And the
> > problem doesn't impact Windows NT client systems.  It also
> doesn't impact
> > WIN32 applications.
> >
> > >Well, all these "oplocks" are a little new to me!
> >
> > Oplocks (short for opportunistics locks) are an optimization for better
> > performance!
> >
> > Oplocks allow a client to cache a file's data locally, without
> > the overhead
> > of continuously syncronizing with the server.  The server can
> grant a read
> > oplock to multiple clients which allows them to cache the file contents
> > without checking for changes on the server - any network
> request to modify
> > the file will cause the server to revoke all read oplocks, which causes
> > clients to revert to normal behavior.  A write oplock can only be
> > granted if
> > a single client has the file open - this allows the client to
> > cache changes
> > to the file locally - whenever another client requests any form
> > of access to
> > the file, the oplock is revoked and the client with the lock must
> > commit any
> > changes to the network copy.
> >
> > >you can put a "oplocks" section in the [global] section, to
> > enable oplocks
> > -
> > >are they enabled by default?
> >
> > Oplocks are enabled by default.  It turns out that they result in a
> > significant improvement in throughput.
> >
> > The biggest problem with using oplocks is if you share files
> between unix
> > applications and PC clients - most unixes do not understand the oplock
> > protocol.  Enabling oplocks may result in unexpected caching
> > behavior on the
> > PC clients.
> >
> > Other than that, there is no reason to disable oplocks.
> > Databases work fine
> > with oplocks - if more than one client tries to use the database, then
> > oplocks with be denied (or revoked).  The only case where oplocks are a
> > problem would be a database that is shared between PC and unix client
> > applications.
> >
> > >you can then put a "veto oplocks" section into individual shares
> > ie [data],
> > >to remove oplocks from that particular share.
> >
> > "Veto oplocks" is used to remove oplock behavior from specific
> filenames.
> > If you want to remove oplocking behavior from a share, simply put
> > "oplocks =
> > NO" in the definition of the share.
> >
> > >Why do my Win2k
> > >machines work be default but not my Win98 machines?
> >
> > I'm guessing that this has NOTHING to do with oplocks.  Of
> > course, I haven't
> > heard the whole story, so I could be wrong.
> >
> > sincerely,
> >
> >   - john nelson (john.nelson at teradyne.com)
>
> ***********************************************************************
> This is a confidential communication between sender and
> addressee. If you are not the intended recipient of this message,
> please notify the sender and do not read, copy, use or disclose
> this communication to others. Any opinions or views expressed are
> those of the individual, and unless otherwise stated, are not
> those of the company. All attachments and intellectual rights
> remain the property of GML (NT) Limited.
> ***********************************************************************
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  http://lists.samba.org/mailman/listinfo/samba

***********************************************************************
This is a confidential communication between sender and addressee. If you are not the intended recipient of this message, please notify the sender and do not read, copy, use or disclose this communication to others. Any opinions or views expressed are those of the individual, and unless otherwise stated, are not those of the company. All attachments and intellectual rights remain the property of GML (NT) Limited.
***********************************************************************