2

DOSEMU の下の Linux で、古い DOS FoxPro / Clipper アプリケーションをたくさん実行する必要があります。プログラムは、ネットワーク サーバー (Windows または Linux サーバーの可能性があります) にある「データベース」にアクセスします。

実際、プログラムは正常に動作しましたが、レコードのロックを想定どおりに機能させることができませんでした。プログラムを 2 つの端末 (またはサーバーと任意の端末など) で実行し、両方で同じレコードをロックできます。

現在、Tiny Core Linux をターミナル、Windows XP をサーバーとして使用し、CIFS と最新の DOSEMU (1.4.0) を介して共有ファイルにアクセスしていますが、さまざまな組み合わせのサーバー (Ubuntu 7 から 9、Damn Small Linux 、XP) <-> プロトコル (CIFS、samba、さまざまなバージョンの smbclient) <-> クライアント (サーバーと同じ) 運が悪い

サーバー部分をsambaでoplocksなしで動作するように構成しようとしました（http://oreilly.com/catalog/samba/chapter/book/ch05_05.htmlのO'Reilly Sambaブックロックの章全体を読んだ後）およびXP（ \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\UseOpportunisticLocking = 0) でも問題は解決しません。

何か案は？

ティア、パブロ

4

6 に答える 6

1

@Michael: プログラムは、DOS (Lantastic、WFW) または Windows (95、NT、XP、...) ネットワークで正常に動作します。

動作を再現するための最小限の C プログラムを作成しました。

#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;
}

DOS / Windows では正常に動作しますが (最初の端末はロックできますが、2 番目の端末はロックできません)、DOSEMU の下の Linux では実行に失敗します (ネットワーク共有でプログラムの 2 つのインスタンスを同時に実行でき、どちらも独立してロックを取得できます)。実行シーケンス Linux-Windows / Windows-Linux)。

于 2009-09-18T22:21:44.197 に答える
0

両方のWindows98、Xpワークステーションを使用してsamba共有でdos eposアプリケーションを実行し、samba共有で正しいロック設定を使用してdosmeuを介してアプリケーションを実行することもできます。以下の設定を使用したSamba共有にはさまざまなロック設定があります。

 [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
于 2010-09-02T09:54:05.963 に答える
0

上記のように、この問題が存在することを確認できます。1つの解決策は、共有DBFファイルをWindowsサーバーからLinuxサーバーに移動することです。これらのファイルは、CIFS（SAMBA）を介して関係のあるWindowsパーティと共有でき、vi NFS（-o sync nolockオプションを使用）を関係のあるLinuxパーティと共有できます。それは私たちにとって非常にうまくいきます

ブレット

于 2009-12-28T09:00:30.127 に答える
0

これは、進行中の既知の問題のようです。

バイト範囲ロック (別名 Windows スタイルのレコード ロック) には最新のカーネル バージョンが必要であることは知っていますが、それが 2.4 シリーズに登場したかどうかはわかりません。

DosEMU が機能しない場合は、もう少し「エキゾチック」なものに頼る必要があるかもしれません。おそらく、 KVM 仮想マシンの下でFreeDOSを実行すると、目標に近づくでしょう。 ）。KVM 互換リストの一番下までスクロールして、さまざまな DOS に似たインストールのステータスを確認します。

元の 6.22 インストールを使用する場合は、実際にはそれが最良のオプションになる可能性があります。

于 2010-06-16T19:04:44.370 に答える
0

まず第一に、これらのプログラムはロックについて何らかの手がかりを持っていますか? それらは、ネットワーク共有上の db ファイルで実行されるように作られていますか?

DOS の時代には、ネットワーク共有はそれほど一般的ではありませんでした (そして、そうであったとき、それは Netware と同じくらい一般的でした)。データベースエンジンが、基礎となるdbファイルが共有される可能性があるという考えを持っていない場合、cifsを使用しても問題ありません-ロックされていないため、機能しません.

さて、これを DOS ボックスのネットワーク上ですでに正しく実行していて、Linux にアップグレードしようとしている場合、現在の DOS ネットワークは何ですか? それはcifsですか、それともNetwareに似ていますか? データベース エンジンがネットワーク スタックを認識して何かおかしなことをしている可能性はありますか? これにより、db エンジンがネットワークを認識しない新しい環境で問題が発生する可能性があります。

何が起こっているのかを本当に把握する必要がある場合は、Wireshark を使用して CIFS トラフィックを追跡し、ロックがどのように使用されているか (または使用されていないか) を理解しようとすることをお勧めします。ただし、これは大変な作業であり、テスト用の簡単なアプリをいくつか生成できない限り、大変な作業になります。

于 2009-09-18T21:32:00.257 に答える