views:

548

answers:

5

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

A: 

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.

Michael Kohne
Clipper was definitely used for multiple clients hitting one network share both Novell and MS-Net (I used dos ms net)
Mark
Alan B
A: 

@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).

PabloG
Someone else had the same issue Oh does http://www.mail-archive.com/[email protected]/msg04683.html
Mark
A: 

Hi,

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

Brett
A: 

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.

Avery Payne
A: 

Hi

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

Regards

Noel McShane

Noel McShane