В баге http://bugs.etersoft.ru/show_bug.cgi?id=5798 был разработан новый механизм работы блокировок для WINE. Данный подход существенно увеличил скорость работы с блокировками, но неприменим для существующего режима wine в CIFS. Надо проверить можно ли подобрать конфигурацию, при которой данный режим может работать на CIFS.
Начали разбираться с amorozov@ с данной багой. Столкнулись с проблемой fstat на cifs, из-за которой блокировка устанавливалась от вайн сервера, а не приложения.
Разобрался с проблемой. Использовалась структура stat, у которой поле айнод номера 32 битное. При взаимодействии с Windows сервером клиент получал номер 64 битный номер от сервера - происходило преполнение. При работе с Samba сервером проблем замечено не было. Решений два: 1) добавить __USE_FILE_OFFSET64 перед #include <sys/stat.h>. 2) использовать структуру stat64. Так же заметил, что в man по mount.cifs присутствует ошибка: "Client generates inode numbers (rather than using the actual one from the server) by default" На самом же деле по умолчанию в клиенте используются номера айнодов со стороны сервера. Написал об этом разработчикам. После применения одного из этих подходов, первые три пункта работают.
Добавил #define _FILE_OFFSET_BITS 64. Сделал, чтобы новый механизм работы блокировок можно было включить на cifs, установив в "yes" переменную окружения WINECIFSWITHOUTPIDFORWARD. Также можно прописать export WINECIFSWITHOUTPIDFORWARD=yes в /etc/wine/config. Потом можно будет сделать, чтобы этот механизм работал по умолчанию.
amorozov@, а что по поводу 4-ого пункта проверки? 4) 1С: 4.1) монитор пользователей, блокировка документа, одновременнная проводка. 4.2) открытие документа на запись и печать документа на принтере - после окончании печати документ всё ещё заблокирован, а после закрытия документа блокировка снимается успешно (проверка на то, что программа печати не влияет на блокировки установленные самой 1С).
> 4.1) монитор пользователей, блокировка документа, одновременнная проводка. Что подразумевается под блокировкой документа и одновременной проводкой? Можно по-подробнее?
(В ответ на comment #5) > > 4.1) монитор пользователей, блокировка документа, одновременнная проводка. > Что подразумевается под блокировкой документа и одновременной > проводкой? Можно по-подробнее? Блокировка: открытие документа на запись из одного клиента, из другого - невозможность открыть этот же документ. Одновременная проводка: на обоих клиентах практически одновременно начинается проведение одного и того же документа.
> Одновременная проводка: на обоих клиентах практически одновременно начинается > проведение одного и того же документа. А можно ещё поподробнее про проведение документа.
Как запустить проведение документа - вопрос к @night или @baraka.
При входе в монитор пользователей 1С зависает.
> При входе в монитор пользователей 1С зависает. 1С 7.7, база base77 в //winxp/Rarus (1С:Бухгалтерия 7.7. Типовая конфигурация, редакция 4.5, 1C/1Cv77_configs/Tipovaya/478_20.06). Если подождать, то выводится ошибка "Ошибка блокировки файла an unnamed file".
Проблема вызвана неудачей при установке эксклюзивной блокировки на файл, открытый только для чтения.
> При входе в монитор пользователей 1С зависает. Исправил.
Проверил работу 1С 7.7 по пунктам, укзанным в комментарии 4. Всё ОК. Одновременную проводку проверял как описано здесь: http://bugs.etersoft.ru/show_bug.cgi?id=3807#c5 При тестировании исользовал машины atlant (2.6.38-std-def-alt2), ALT Linux 5.0.2 school-master на virtualbox (2.6.32-std-def-alt20.M50P.1) и winxp. Параметры монтирования и версия etercifs те же, что раньше (http://bugs.etersoft.ru/show_bug.cgi?id=5798#c49).
(В ответ на comment #13) > Проверил работу 1С 7.7 по пунктам, укзанным в комментарии 4. Всё ОК. > Одновременную проводку проверял как описано здесь: > http://bugs.etersoft.ru/show_bug.cgi?id=3807#c5 > > При тестировании исользовал машины atlant (2.6.38-std-def-alt2), ALT Linux > 5.0.2 school-master на virtualbox (2.6.32-std-def-alt20.M50P.1) и winxp. > Параметры монтирования и версия etercifs те же, что раньше > (http://bugs.etersoft.ru/show_bug.cgi?id=5798#c49). Когда примерно будет готова сборка с патчами по багам 5798 и 7302? А то везде все хорошо - обе баги 100% завершены и исправлены - а тестить-использовать нечего.. Последний раз проверял 24.05.11. Если после этого уже вышла тестовая сборка - прошу извинить..
К сожалению testing сборки еще нету, в ближайшие пару дней будет. (В ответ на comment #14) > Когда примерно будет готова сборка с патчами по багам 5798 и 7302? А то везде > все хорошо - обе баги 100% завершены и исправлены - а тестить-использовать > нечего.. Последний раз проверял 24.05.11. Если после этого уже вышла тестовая > сборка - прошу извинить..
Заключение по данному вопросу: для правильной работы в новом режиме CIFS нужен механизм кэширования блокировок (наработки можно взять отсюда http://bugs.etersoft.ru/show_bug.cgi?id=5442), так как: VFS ядра имеет такую неприятную особенность - сбрасывать кэш когда ему покажется что его слишком много при этом сбрасывает оно от нулевого процесса. Если раньше можно было просто выставить пид от процесса открывшего файл(сохранённый в данных о файловом дескрипторе) то теперь нельзя выяснить, какой пид выставлять, чтобы не обломиться о собственную блокировку, так как по новому режиму блокировку ставит сам wine процесс. Если же все блокировки будут обрабатываться локально, то всё ок - можно сбрасывать данные под любым пидом. Всё вышесказанное справедливо при режиме работы одного пользователя. Когда два пользователя и на файле есть блокировки - кэш не используется вообще. Так же следует добавить, что такой режим необходим для правильной работы с жёсткими блокировками реализации нового режима кэширования из SMB2.1 в CIFS клиенте.
(В ответ на comment #3) > Добавил #define _FILE_OFFSET_BITS 64. Так и не понял, куда добавил, вроде это везде (и в открытой и закрытой части) и так было.
> > Добавил #define _FILE_OFFSET_BITS 64. > Так и не понял, куда добавил, вроде это везде (и в открытой и закрытой части) и > так было. В lib/fd.c в закрытой части.
