problems with locking

problems with locking

[Siim Vahtre]

Hi.

I need to use some dosemu clients(running old database programs made in
turbo pascal) that read/write paradox databases on linux samba server.
However, it seems that samba and dosemu doesn't share their thoughts about
file locking.

For example, when I open (read-only!) some file (let's say "L:\test.txt"
that is actually "/mnt/samba/test.txt") then I can't open the same file
with another dosemu. (It says "Access denied.")

smbstatus shows:
Pid    DenyMode    R/W  Oplock Name
2347   DENY_NONE   RDRW NONE   /mnt/samba/test.txt

DenyMode is DENY_NONE, so I should be able to at least open the file
read_only from another client aswell, right?

Dosemu version is 1.0.2
Samba version is 2.2.3a-6
The OS on Dosemu is FreeDOS (1.1.24c)

And even if I can get this to work... will I be able to use bytelocking
(for databases) aswell?

Or in general - does anyone know how well one old TPascal program with
paradox databases might work on dosemu?

Any hints/helps are deeply appreciated.

Re: problems with locking

[Siim Vahtre]

> For example, when I open (read-only!) some file (let's say "L:\test.txt"
> that is actually "/mnt/samba/test.txt") then I can't open the same file
> with another dosemu. (It says "Access denied.")

One thing more:
It does not matter HOW I configure the samba. Even if there  is no locking
whatsoever, I STILL cannot look at file someone else is _reading_.

If anyone knows how, please help.

Re: problems with locking

[Michal Samek]

On St, 2002-11-06 at 12:55, Siim Vahtre wrote:
> > For example, when I open (read-only!) some file (let's say "L:\test.txt"
> > that is actually "/mnt/samba/test.txt") then I can't open the same file
> > with another dosemu. (It says "Access denied.")

OK, there ARE 2 locking problems. One with a file lock and another with
a record lock. Try to search archives. Try 1.1.3 version, for some
people it seems to work (not for me and for some clipper users i
think).  But  what do you try with test.txt is maybe ok, when I open for
ex. with NC some file for reading (F3 - view file), it opens the file in
DENY-ALL mode and it should deny other sessions to open the file.

> 
> One thing more:
> It does not matter HOW I configure the samba. Even if there  is no locking
> whatsoever, I STILL cannot look at file someone else is _reading_.
> 
> If anyone knows how, please help.
> 



-- 
Michal Samek <webmaster@tony.cz>

Re: problems with locking

[Siim Vahtre]

> OK, there ARE 2 locking problems. One with a file lock and another with
> a record lock. Try to search archives. Try 1.1.3 version, for some
> people it seems to work (not for me and for some clipper users i
> think).  But  what do you try with test.txt is maybe ok, when I open for
> ex. with NC some file for reading (F3 - view file), it opens the file in
> DENY-ALL mode and it should deny other sessions to open the file.

I tried 1.1.3 aswell. Exactly the same  :(

I also tried to change the os on it. (drdos and various versions of
freedos). No luck whatsoever.

Whatever I do, "DENY_NONE" and "Oplock:" none is unreadable by others.

Re: problems with locking

[Stephen Lee]

On Wed, 2002-11-06 at 06:20, Siim Vahtre wrote:
> > OK, there ARE 2 locking problems. One with a file lock and another with
> > a record lock. Try to search archives. Try 1.1.3 version, for some
> > people it seems to work (not for me and for some clipper users i
> > think).  But  what do you try with test.txt is maybe ok, when I open for
> > ex. with NC some file for reading (F3 - view file), it opens the file in
> > DENY-ALL mode and it should deny other sessions to open the file.
> 
> I tried 1.1.3 aswell. Exactly the same  :(
> 

Try it with the latest patches (1.1.3.7) at
http://www.dosemu.org/testing. I had to use the patches, starting with
1.1.3.3, before Foxpro and Samba would recognize each others locks.

Stephen

Re: problems with locking

[Siim Vahtre]

> Try it with the latest patches (1.1.3.7) at

It works!
I now just hope that this testing version is 'stable' enough.

Thank you!

Re: problems with locking

[Siim Vahtre]

> > Try it with the latest patches (1.1.3.7) at
>
> It works!

*sigh*
It doesn't work :)

The samba has shared everything well. Windows clients get done their
locking correctly. However, when dosemu clients come, they don't care
about locking any more. Even if they are exclusive locks that should
forbid even reading. All the locks are downgraded to DENY_NONE and
everything can always be readed/writed. Alas.

I even tried strict locking aso... nothing worked.

dosemu locking capabilities

[Siim Vahtre]

How much ways dosemu actually knows to lock one file?

As I mentioned already, I need quite special way of locking files (paradox
databases). It must be able to lock one certain record, that is being
changed, and leave every other record readable/writeable.

Can dosemu handle it in any way?
(I'm not sure even if DOS can...)

Atm, I have tried thousands of different ways to do it (many different
versions of samba, dosemu, freedos/drdos, etc) but I have not been able
to (even not for once) get different locking than just this simple
"OpLocks: none" and "DenyMode: DENY_NONE", which basicly is quite
'nothing' for me. (It doesn't forbid anyone to corrupt the data.)

Am I doing something totally wrong or isn't it really possible to be able
to lock files in more complex way? (The Windows boxes using the same
samba fileserver locked correctly, so it must be dosemu's problem, right?)

I'm really sorry if I'm just wasting your time with stupid questions but
all those long hours with 'gain: zero' are getting depressing ;-)

Re: dosemu locking capabilities

[Stephen Lee]

On Wed, 2002-11-06 at 12:58, Siim Vahtre wrote:
> 
> How much ways dosemu actually knows to lock one file?
> 
> As I mentioned already, I need quite special way of locking files (paradox
> databases). It must be able to lock one certain record, that is being
> changed, and leave every other record readable/writeable.
> 
> Can dosemu handle it in any way?
> (I'm not sure even if DOS can...)
> 
> Atm, I have tried thousands of different ways to do it (many different
> versions of samba, dosemu, freedos/drdos, etc) but I have not been able
> to (even not for once) get different locking than just this simple
> "OpLocks: none" and "DenyMode: DENY_NONE", which basicly is quite
> 'nothing' for me. (It doesn't forbid anyone to corrupt the data.)
> 
> Am I doing something totally wrong or isn't it really possible to be able
> to lock files in more complex way? (The Windows boxes using the same
> samba fileserver locked correctly, so it must be dosemu's problem, right?)
> 
> I'm really sorry if I'm just wasting your time with stupid questions but
> all those long hours with 'gain: zero' are getting depressing ;-)

Hang in there ;-) I use Foxpro so the locking requirements look to be
different than for Clipper. Hopefully the developers can chime in and
ask for some diagnostic output.

Stephen

Re: dosemu locking capabilities

[Bart Oldeman]

On Wed, 6 Nov 2002, Siim Vahtre wrote:

> How much ways dosemu actually knows to lock one file?

just a few days ago I wrote down the way how DOSEMU handles file locking 
now (since 1.1.3.3) here:
http://marc.theaimsgroup.com/?l=linux-msdos&m=103627393213889&w=2
see src/dosext/mfs/mfs.c for the implementation.

There is a fundamental problem in that DOS locking is incompatible with 
UNIX locking. Now if you use smbfs and samba you add two extra layers 
where things can go wrong. This makes it complex. If the file server is 
not running Windows then it's probably better to use NFS instead.

The locking mechanism I did not mention was region locking, which however 
can probably be solved now in certain cases by using the 64-bit 
lock functions. See
http://marc.theaimsgroup.com/?l=linux-msdos&m=103626684509236&w=2
(this is not implemented yet; patches are welcome :)

Bart

Re: dosemu locking capabilities

[Siim Vahtre]

> There is a fundamental problem in that DOS locking is incompatible with
> UNIX locking. Now if you use smbfs and samba you add two extra layers
> where things can go wrong. This makes it complex. If the file server is
> not running Windows then it's probably better to use NFS instead.

The file server is Linux. However, there are also some Windows machines
who want to say a word. And they all(Dosemu and Windows clients) must work
together well.

> The locking mechanism I did not mention was region locking, which however
> can probably be solved now in certain cases by using the 64-bit
> lock functions. See
> http://marc.theaimsgroup.com/?l=linux-msdos&m=103626684509236&w=2
> (this is not implemented yet; patches are welcome :)

So region locking does not work at all (atm)?
In any case? (That is my primary concern, actually...)

Re: dosemu locking capabilities

[Marcel van der Heide]

On Thursday 07 November 2002 07:21, Siim Vahtre wrote:
> > There is a fundamental problem in that DOS locking is incompatible with
> > UNIX locking. Now if you use smbfs and samba you add two extra layers
> > where things can go wrong. This makes it complex. If the file server is
> > not running Windows then it's probably better to use NFS instead.
>
> The file server is Linux. However, there are also some Windows machines
> who want to say a word. And they all(Dosemu and Windows clients) must work
> together well.

I don't now if this could be a workable solution for you, but I suggest that 
you forget about smbfs and samba. If your app runs fine under dosemu, simply 
telnet (or ssh if security is a concern) from the windows and linux clients 
to the linux server and run the app there under dosemu. Most likely you'll 
gain speed too, because the app's data doesn't need to be transferred over 
the network. I use this setup at a number of sites. The telnet client I use 
on the windows machines is Console Telnet v2.0 
(http://consoletelnet.sourceforge.net/). Development of it seems to be 
standing still, but it works fine after you define some more key 
combinations.

I hope that I've been clear and that this will help you.

Best wishes,

Marcel

Re: dosemu locking capabilities

[Anderson Pereira Ataides]

Marcel,

I believe this is a solution, not the best, but a solution. The problem is 
that I tried this once  but did not work. When I locked a file in a login 
session, a second one could not check that file was locked and aborded.

Also, i did not tried with patchset 1.1.3.7, but locking is a problem with NFS 
too. If it works with NFS, I am really next to leave Windows workstations and 
use Linux + dosemu in all of them.

[]s
Anderson Pereira Ataides

Em Qui 07 Nov 2002 08:43, Marcel van der Heide escreveu:
>
> I don't now if this could be a workable solution for you, but I suggest
> that you forget about smbfs and samba. If your app runs fine under dosemu,
> simply telnet (or ssh if security is a concern) from the windows and linux
> clients to the linux server and run the app there under dosemu. Most likely
> you'll gain speed too, because the app's data doesn't need to be
> transferred over the network. I use this setup at a number of sites. The
> telnet client I use on the windows machines is Console Telnet v2.0
> (http://consoletelnet.sourceforge.net/). Development of it seems to be
> standing still, but it works fine after you define some more key
> combinations.
>
> I hope that I've been clear and that this will help you.
>
> Best wishes,
>
> Marcel
> -
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dosemu locking capabilities

[Marcel van der Heide]

On Friday 08 November 2002 00:22, Anderson Pereira Ataides wrote:

> I believe this is a solution, not the best, but a solution. The problem is
> that I tried this once  but did not work. When I locked a file in a login
> session, a second one could not check that file was locked and aborded.
>
> Also, i did not tried with patchset 1.1.3.7, but locking is a problem with
> NFS too. If it works with NFS, I am really next to leave Windows
> workstations and use Linux + dosemu in all of them.

Our app doesn't use locking of a region, it just locks the whole file and that 
works fine under dosemu 1.0.x. If locking of a region doesn't work, than that 
is something that should be fixed in dosemu.

My solution eliminates the problem of stacking multiple layers of software on 
top of each other while they don't understand each other's locking 
implementation (and gives a great speedup if you process a lot of data). 

If you are thinking of dumping windows alltogether, maybe you'll be 
interrested in the Linux terminal server project (http://www.ltsp.org). It 
lets the workstations boot via (bootrom / PXE / bootrom image on floppy) from 
the server. No software to install and maintain on each workstation. I am 
starting to use it and it works great.

Best wishes,

Marcel

Re: dosemu locking capabilities

[Siim Vahtre]

> I don't now if this could be a workable solution for you, but I suggest that
> you forget about smbfs and samba. If your app runs fine under dosemu, simply
> telnet (or ssh if security is a concern) from the windows and linux clients
> to the linux server and run the app there under dosemu.

I also need mouse. SSH knows how to send mouseclicks and some apps even
know how to use them over terminal (links, for example) but last time I
tried Dosemu was not able to use mouse in that way.

Re: dosemu locking capabilities

[Bart Oldeman]

> The file server is Linux. However, there are also some Windows machines
> who want to say a word. And they all(Dosemu and Windows clients) must work
> together well.

Well you could use NFS to export to Linux clients and Samba to export to
Windows clients for the same directory.

> > The locking mechanism I did not mention was region locking, which however
> > can probably be solved now in certain cases by using the 64-bit
> > lock functions. See
> > http://marc.theaimsgroup.com/?l=linux-msdos&m=103626684509236&w=2
> > (this is not implemented yet; patches are welcome :)
>
> So region locking does not work at all (atm)?
> In any case? (That is my primary concern, actually...)

Oh it does work for certain situations. It all depends what the DOS app
does (i.e. problems start when non-existing regions are locked, using
offsets past the end of the database). 32-bit lock offsets in Linux are
signed and 32-bit lock offsets in DOS are unsigned.

Bart