Проблема блокировки записи между Linux и Windows

@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 (первый терминал может заблокировать, а второй нет), но не работает в Linux под DOSEMU (вы можете одновременно запускать два экземпляра программы в сетевом ресурсе, и оба могут получить блокировку независимо от последовательность выполнения Linux-Windows / Windows-Linux).

Прежде всего: есть ли у этих программ какое-либо представление о блокировке? Они сделаны для запуска с файлом db на сетевом ресурсе?

Во времена DOS сетевые ресурсы не были очень распространены (и когда это было, то чаще всего это была Netware). Если у механизма базы данных нет никаких идей о том, что базовый файл базы данных может быть общим, то не имеет значения, что вы используете с cifs - он не блокируется, поэтому он не будет работать.

Теперь, если вы уже правильно используете это в сети компьютеров DOS и пытаетесь перейти на Linux, какая текущая сеть DOS? Это cifs или больше похоже на Netware? Есть ли шанс, что механизм базы данных знает о сетевом стеке и делает что-то смешное? Это может привести к проблемам в новой среде, где механизм базы данных не знает о сети.

Если вам действительно нужно выяснить, что происходит, вы можете попробовать использовать Wireshark для отслеживания трафика CIFS и попытаться понять, как он использует (или не использует) блокировку. Однако это большие усилия, и если вы не можете создать несколько тривиальных приложений для тестирования, то это много работы.

Я могу подтвердить, что эта проблема действительно существует, как указано выше. Одним из решений является перенос общих файлов DBF с сервера Windows на сервер Linux. затем эти файлы могут быть переданы через CIFS (SAMBA) заинтересованным сторонам Windows и через vi NFS (с параметрами -o sync nolock) заинтересованным сторонам Linux. Это работает для нас довольно хорошо

Бретт

Похоже, это известная, нерешенная проблема.

Я знаю, что блокировка диапазона байтов (также известная как блокировка записей в стиле Windows) требует последних версий ядра, хотя я не знаю, появилась ли она в серии 2.4 или нет.

Если DosEMU не может работать на вас, возможно, вам придется прибегнуть к чему-то более «экзотическому». Возможно, запуск FreeDOS под Виртуальная машина KVM приблизит вас к вашим целям, хотя вам придется выполнить некоторые настройки вручную, чтобы получить сетевую поддержку (это или выяснить, как сделать сетевую папку отображаться как буква локального диска в гостевой системе). Прокрутите вниз список совместимости KVM, чтобы увидеть статус различных установок, подобных DOS.

Если у вас есть оригинальные установки 6.22 для работы, то это может быть лучшим вариантом.

Мы запускаем приложение dos epos на общем ресурсе samba на обеих рабочих станциях Windows 98, Xp с правильной настройкой блокировки на общем ресурсе 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

Ответ на самом деле довольно прост: posix-блокировки не подходят для этой задачи. И это все, что у нас было до конца 2014 года, когда linux-3.15 и glibc-2.20 начали предоставлять блокировки OFD — через 5 лет после того, как здесь был задан этот вопрос.

CIFS получил блокировки OFD только в 2018 году: https://www.spinics.net/lists/linux-cifs/msg14795.html

Вisemu2 имеет экспериментальную поддержку блокировок OFD в git (2020).

Итак, чтобы ответить на ваш вопрос: технологии 2009 года (когда был опубликован этот вопрос) не были достаточно продвинуты для выполнения вашей задачи. На самом деле работа была начата только спустя 5 лет, когда linux получил блокировку OFD, и потребовалось 6+ лет, чтобы все остальные задействованные программные компоненты подтянулись.

Примечание: помимо блокировки записей, foxpro/cliper также заинтересованы в так называемой поддержке общих ресурсов - еще одной технологии от MS, которая по своей сути несовместима с posix. Поддержка общего доступа не будет работать в вашем сценарии даже сейчас. В лучшем случае вы можете получить надлежащую поддержку общего доступа между несколькими сеансами dosemu2, работающими на одном компьютере. Но вы не получите общий доступ, если одновременно откроете свои файлы на своем сервере Windows и в разделе «Dosemu2». И даже если вы запустите несколько экземпляров dosemu2 на разных машинах, поддержка общего доступа не гарантируется. Но если все, что вам нужно, это блокировка региона, то она будет работать во всех конфигурациях, если ваше программное обеспечение достаточно свежее.