Record locking problem between linux and Windows

Question

I need to run a bunch of old DOS FoxPro / Clipper applications in linux under DOSEMU. The programs access their "databases" located on a network server (could be a Windows or Linux server)

Actually, the programs ran fine, but I cannot manage to make the record locking work as supposed: I can run a program in two terminals (or the server and any terminal for instance) and lock the same record in both.

Now, I'm using Tiny Core Linux as terminal and Windows XP as server, accesing the shared files via CIFS and the latest DOSEMU (1.4.0), but I tried with various combinations of server (Ubuntu 7 to 9, Damn Small Linux, XP) <-> protocol (CIFS, samba, various versions of smbclient) <-> client (same as server) with no luck

I tried to configure the server part to work without oplocks in samba (after reading the entire O'Reilly Samba book locking chapter in http://oreilly.com/catalog/samba/chapter/book/ch05_05.html ) and in XP (\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\UseOpportunisticLocking = 0) but the problem persist.

Any ideas?

TIA, Pablo

Answer 1

The answer is actually quite simple: posix locks are not suitable for that task. And this is all we had until late 2014, when linux-3.15 and glibc-2.20 started to provide OFD locks - 5 years after this question was asked here.

CIFS only got OFD locks in 2018: https://www.spinics.net/lists/linux-cifs/msg14795.html

dosemu2 has experimental OFD locks support in git (2020).

So, to answer your question: the technologies of 2009 (when that question was posted) were not advanced enough to perform your task. In fact, the work was started only 5 years later, when linux got OFD locks, and it took 6+ years for all other involved software components to catch up.

Note: besides record locking, foxpro/clipper are also "interested" in a so called "share support" - another technology from MS, that is inherently incompatible with posix. Share support will not work in your scenario even now. At best, you can get proper share support between multiple dosemu2 sessions running on the same machine. But you won't get share if you open your files on your windows server and under dosemu2 at the same time. And even if you run several dosemu2 instances on different machines, share support is not guaranteed to work. But if all you need is region locking, then it will work in all configurations, in case your software is recent enough.

Answer 2

We run a dos epos application on a samba share with both windows 98,Xp workstations with the correct locking setting on the samba share we are also able to run the application through dosmeu. There are a range of lock setting on the samba share we used the following settings.

 [data]
        comment = data Share
        inherit acls = Yes
        path = /data/
        read only = No
        oplocks = no
        locking = Yes
        strict locking = No
        create mask = 0774
        directory mask = 0775
        browseable = Yes
        default case = upper

Answer 3

This appears to be a known, ongoing issue.

I do know that byte-range locking (aka Windows-style record locking) requires recent kernel versions, although I don't know if it appeared in the 2.4 series or not.

If DosEMU cannot be made to work for you, you might have to resort to something a little more "exotic". Perhaps running FreeDOS under a KVM virtual machine would get you closer to your goals, although you'll have to do some manual setup to get networking support (that or figure out how to make a network share appear as a local drive letter in the guest). Scroll to the bottom of the KVM compat list to see the status of various DOS-like installs.

If you have the original 6.22 installs to work with then that might actually be your best option.

Answer 4

I can confirm this problem does exist as indicated above. One solution is to move the shared DBF files off of the windows server and onto a linux server. these files can then be shared via CIFS (SAMBA) to interested windows parties and vi NFS (with the -o sync nolock options) to interested linux parties. It works for us quite well

Brett

Answer 5

@Michael: the programs works fine on any DOS (Lantastic, WFW) or Windows (95, NT, XP, ...) network.

I created a minimal C program to reproduce the behavior:

#include <io.h>
#include <fcntl.h>
#include <sys\stat.h>
#include <process.h>
#include <share.h>
#include <stdio.h>
#include <conio.h>

int main(void)
{
 int handle, status;
 long length;

 handle = sopen("testlock.txt", O_RDONLY,SH_DENYNO,S_IREAD);

 if (!handle)
 {
    printf("sopen failed\n");
    exit(1);
 }

 length = filelength(handle);
 status = lock(handle,0L,length/2);

 if (status == 0)
    printf("lock succeeded\n");
 else
    printf("lock failed\n");

 printf ("Press a key...\n");
 getch();

 status = unlock(handle,0L,length/2);

 if (status == 0)
    printf("unlock succeeded\n");
 else
    printf("unlock failed\n");

 close(handle);
 return 0;
}

It works fine on DOS / Windows (the first terminal can lock, the 2nd one no), but fails executing in Linux under DOSEMU (you can concurrently run two instances of the program in a network share, and both can obtain the lock independently of the run sequence Linux-Windows / Windows-Linux).

Answer 6

First off: Do these programs have any clue about locking? Are they made to be run with the db file on a network share?

Back in the DOS days, a network share wasn't real common (and when it was, it was Netware as often as not). If the database engine doesn't have any ideas that the underlying db file might be shared, then it doesn't matter what you with cifs - it's not locking, so it's not going to work.

Now, if you are already running this correctly on a network of DOS boxes and you are trying to upgrade to Linux, what's the current DOS network? Is it cifs, or is it more like Netware? Is there any chance that the database engine is aware of the network stack and doing something funny? That might lead to problems in a new environment where the db engine isn't aware of the network.

If you really need to figure out what's going on, you might try using Wireshark to trace the CIFS traffic and try to understand how it's using (or not using) locking. That's a big effort though, and unless you can generate some trivial apps to test with, then it's a lot of work.