Сейчас блокировки на CIFS mandatory. Если один процесс заблокировал участок в файле, то другой процесс не может с ним работать (см. man 2 fcntl). Это вызывает проблемы в работе WINE, так как в нём в ряде случаев одновременно с файлом должны работать 2 процесса. Надо разобраться, можно ли сделать так, чтобы блокировки были advisory, то есть чтобы они не препятствовали чтению и записи в файл со стороны не владеющего блокировкой процесса. Не вызовет ли это проблем с совместной работой с Windows-приложениями? В принципе, у проблемы, возможно, существует и второй вариант решения: перенос вызовов fcntl из wineserver в используемые прикладными программами dll. То есть, если окажется, что переделка поведения блокировок нереальна или вызовет проблемы со взаимодействием с Windows, то можно пойти другим путём.
Вообще, суть переделывания Mandatory на Advisory мне непонятна... По сути, всё верно... Процессы разные - доступ разграничен. Повторное открытие файла происходит не явно, причём ещё не ясно можно ли отличить открытие второго файлового дескриптора, при его пробрасывании через unix-сокет на уровне CIFS. Мне пока это не ясно... Ясно то, что это исправление сломает совместную работу... Ведь, когда мы сами, в одном процессе, заблокировали файл, а потом хотим получить к нему доступ из другого процесса, то сервер должен пропустить операцию вопреки вынужденной блокировке. При этом сервер не отличает откуда был осуществлён доступ с одного и того же хоста или нет... То есть нужно обмануть сервер, но сервер сам разрешает или не разрешает, соответственно исправлять нужно сервер. Думаю, что сервер исправлять мы не будем... Если только сразу вести речь, что он у нас свой... Всё, что я могу придумать, в соответствии с архитектурой wine, это попытаться найти в коде CIFS вызов дублицирования файлового дескриптора, при передаче через unix-сокет, и выяснить можно ли это действие отличить от обычного открытия файла. Если это удастся, то вместо идентификатора процесса wine-приложения можно подсовывать идентификатор процесса winserver'а. Локальные же вопросы блокировок для процессов одного пользователя придётся возложить на сам сервер (он и так вроде бы этим занимается)... Пока я не могу сказать в какие сроки получится, и получится или вообще, реализовать этот костыль. Думаю, что к пятнице или, в худшем случае, к понедельнику, это будет понятно... Со своей стороны хочу уточнить, а что действительно мешает перенести блокировки в процесс клиента? Я так понял, что смысл этого механизма с блокировками на wine-сервере, был в том, чтобы эмулировать файловые блокировки в случае отсутствия их поддержки на файловой системе. По крайней мере именно так я понял это из описания для разработчиков: http://www.winehq.org/docs/winedev-guide/x3062
Мешает разве что возможный объём изменений и то, что в будущем могут быть проблемы с мерджем с основной веткой, хотя, в принципе, эти места вроде особо не трогают. Хотя в принципе это вроде реализуемо.
Нашёл пока единственный способо обмануть сервер - в режиме nounix заменить отправляемый tgid/pid на uid и отдать разрешение блокировок на файлах в рамках операций одного пользователя на откуп wineserver'у. Вот только кода там немало на pid'ы завязано: $ grep "current->tgid" -R . ./cifssmb.c: pSMB->Locks[0].Pid = cpu_to_le16(current->tgid); ./cifssmb.c: parm_data->pid = cpu_to_le32(current->tgid); ./tgid:./cifssmb.c: pSMB->Locks[0].Pid = cpu_to_le16(current->tgid); ./tgid:./cifssmb.c: parm_data->pid = cpu_to_le32(current->tgid); ./tgid:./file.c: private_data->pid = current->tgid; ./tgid:./file.c: (pCifsFile->pid == current->tgid)) { ./tgid:./file.c: (!any_available && open_file->pid != current->tgid)) ./tgid:./tpid:./cifssmb.c: pSMB->Locks[0].Pid = cpu_to_le16(current->tgid); ./tgid:./tpid:./cifssmb.c: parm_data->pid = cpu_to_le32(current->tgid); ./tgid:./tpid:./file.c: private_data->pid = current->tgid; ./tgid:./tpid:./file.c: (pCifsFile->pid == current->tgid)) { ./tgid:./tpid:./file.c: (!any_available && open_file->pid != current->tgid)) ./tgid:./tpid:./misc.c: buffer->Pid = cpu_to_le16((__u16)current->tgid); ./tgid:./tpid:./misc.c: buffer->PidHigh = cpu_to_le16((__u16)(current->tgid >> 16)); ./tgid:./tpid:./inode.c: netpid = current->tgid; ./tgid:./tpid:./inode.c: current->tgid); ./tgid:./tpid:./inode.c: current->tgid); ./tgid:./tpid:./inode.c: current->tgid)) ./tgid:./tpid:./dir.c: pCifsFile->pid = current->tgid; ./tgid:./misc.c: buffer->Pid = cpu_to_le16((__u16)current->tgid); ./tgid:./misc.c: buffer->PidHigh = cpu_to_le16((__u16)(current->tgid >> 16)); ./tgid:./inode.c: netpid = current->tgid; ./tgid:./inode.c: current->tgid); ./tgid:./inode.c: current->tgid); ./tgid:./inode.c: current->tgid)) ./tgid:./dir.c: pCifsFile->pid = current->tgid; ./file.c: private_data->pid = current->tgid; ./file.c: (pCifsFile->pid == current->tgid)) { ./file.c: (!any_available && open_file->pid != current->tgid)) ./tpid:./cifssmb.c: pSMB->Locks[0].Pid = cpu_to_le16(current->tgid); ./tpid:./cifssmb.c: parm_data->pid = cpu_to_le32(current->tgid); ./tpid:./file.c: private_data->pid = current->tgid; ./tpid:./file.c: (pCifsFile->pid == current->tgid)) { ./tpid:./file.c: (!any_available && open_file->pid != current->tgid)) ./tpid:./misc.c: buffer->Pid = cpu_to_le16((__u16)current->tgid); ./tpid:./misc.c: buffer->PidHigh = cpu_to_le16((__u16)(current->tgid >> 16)); ./tpid:./inode.c: netpid = current->tgid; ./tpid:./inode.c: current->tgid); ./tpid:./inode.c: current->tgid); ./tpid:./inode.c: current->tgid)) ./tpid:./dir.c: pCifsFile->pid = current->tgid; ./misc.c: buffer->Pid = cpu_to_le16((__u16)current->tgid); ./misc.c: buffer->PidHigh = cpu_to_le16((__u16)(current->tgid >> 16)); ./inode.c: netpid = current->tgid; ./inode.c: current->tgid); ./inode.c: current->tgid); ./inode.c: current->tgid)) ./dir.c: pCifsFile->pid = current->tgid; Не уверен, что это получится быстро сделать и отладить... Пока я хочу определиться с принципиальным вопросом. Никого не пугает такой вариант? Может есть другие предложения, "как сделать из mandatory блокировок advisory в рамках одного пользователя на одном хосте на CIFS", чтобы это вписывалось в архитекутуру блокировок на wineserver'е? Мне кажется, что задача того не стоит... Всё-таки это архитектурная особенность winserver'а.
Проявился один прямой путь... Если я правильно понял суть вызова dup(), и того, что делается при пробросе файловых дескрипторов через unix-сокет, то повторного открытия файла не происходит. Происходит создание ссылки на открытый файл в пространстве файловых дескрипторов процесса. При этом, изменение pid'a или tgid'а должно прослеживаться. Так, что если его заранее запомнить, а потом проверять, то этот хак может помочь восстанавливать исходные pid или tgid wineserver'а. Стоит учесть, что wine-процессы одного пользователя на заданном хосте будут выглядеть для Samba, как запущенные из одного и того же процесса... И wineserver должен будет это разрешать собственными силами... Тут возникает такой вопрос: а что произойдёт, когда потребуется совместная работа нескольких приложений одного и того же пользователя на одном и том же хосте? Вообще такая ситуация была всегда. Архитектура wine предполагает открытие файлов одного пользователя выполняется на winserver'е. А, соответственно, Samba или Windows различали эти процессы, только по косвенным признакам.
> Стоит учесть, что wine-процессы одного > пользователя на заданном хосте будут > выглядеть для Samba, как запущенные из одного > и того же процесса... И wineserver должен будет > это разрешать собственными силами... > > Тут возникает такой вопрос: а что > произойдёт, когда потребуется совместная > работа нескольких приложений одного и того > же пользователя на одном и том же хосте? По идее, это ситуация, аналогичная совместной работе нескольких WINE-программ из одной .wine локально или на NFS.
(In reply to comment #4) ... > Стоит учесть, что wine-процессы одного > пользователя на заданном хосте будут > выглядеть для Samba, как запущенные из одного > и того же процесса... И wineserver должен будет > это разрешать собственными силами... > > Тут возникает такой вопрос: а что > произойдёт, когда потребуется совместная > работа нескольких приложений одного и того > же пользователя на одном и том же хосте? Да, wineserver сам отслеживает блокировки между процессами, запущенные в нём, так что тут проблемы не будет, видимо. Не забудьте только учесть, что один пользователь может запустить несколько wineserver (с разными WINEPREFIX), так что завязаться на uid не получится.
(In reply to comment #6) > (In reply to comment #4) > ... > > Стоит учесть, что wine-процессы одного > > пользователя на заданном хосте будут > > выглядеть для Samba, как запущенные из одного > > и того же процесса... И wineserver должен будет > > это разрешать собственными силами... > > > > Тут возникает такой вопрос: а что > > произойдёт, когда потребуется совместная > > работа нескольких приложений одного и того > > же пользователя на одном и том же хосте? > Да, wineserver сам отслеживает блокировки между > процессами, запущенные в нём, так что тут > проблемы не будет, видимо. Не совсем... В текущем положении уже имеется проблема busy-wait, когда процесс заблокирован wine-сервером. А вдеь данная ситуация будет штатной, во время совместной работы, когда разные пользователи будут пытаться заблокироваться. Вообще, это довольно некрасиво эмулировать блокируемые вызовы активным ожиданием в неблокируемом режиме. Интересно, а ожидание блокировки в LockFileEx, тоже так реализовано? > Не забудьте только учесть, что один > пользователь может запустить несколько > wineserver (с разными WINEPREFIX), так что завязаться > на uid не получится. > Ну, если привязываться к pid'у wineserver'а, то вроде бы проблем быть не должно. Проблемы, я полагаю, будут в другом - в том, что wine не только в одном месте имеет привяку к особенностям unix-семантики и кололежащим костылям...
Created attachment 1326 [details] process locks himself on CIFS, mount with nounix Сделал минимальный тест демонстрирующий проблему на примере двух процессов.
Created attachment 1327 [details] Wine hacks for CIFS with mandatory locking Сделал обвязку, выполняющую вызов основных операций над открытым файлом, с указанием идентификатора процесса, открывшего файл, а не выполняющего операцию. Этот подход Паша уже обсудил и утвердил со Ствиом Френчем, но мой патч пока не помог... Видимо, метод header_assemble() требуется устанавливать правильный PID не только во внешних методах... До внутренних я пока не добрался... Тестовая ветка доступна здесь: http://git.etersoft.ru/people/sin/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/test git://git.etersoft.ru/people/sin/packages/cifs-2.6.git
Created attachment 1328 [details] Extended test for locks with echo process ids Расширенный тест на блокировки при пробрасывании файловых дескрипторов между процессами. Добавлено вычитывание блокировки перед чтением с указанием идентификатора блокирующего процесса.
Как выяснилось, вызов CIFSSMBRead() не единственный участник процесса самоблокирования. При повторном запуске теста видно, что используется кеш, при этом от имени процесса-приложения уходит пакет со своим PID'ом заголовке. Стоит учесть, что после закрытия процесса-сервера, клент - отплипает. # Первый запуск [sin@server wine]$ ./raw4 start 5642 server start 5643 server send 5 fd received=5 (len=1) file locked by 5642 server end done # Второй запуск [sin@server wine]$ ./raw4 start 5656 server start 5657 server send 5 fd received=5 (len=1) file locked by 5656 server end done Первый лог исполнения: Sep 30 19:58:25 server kernel: [1058792.209552] header_assemble with pid=5642 (5642) Sep 30 19:58:25 server kernel: [1058792.210216] header_assemble with pid=5642 (5642) Sep 30 19:58:25 server kernel: [1058792.210219] CIFSSMBOpen() try small_smb_init_with_pid()=0 with pid=5642 Sep 30 19:58:25 server kernel: [1058792.210903] CIFSSMBOpen() try SendReceive()=0 Sep 30 19:58:25 server kernel: [1058792.210924] cifs_readpages start cycle Sep 30 19:58:25 server kernel: [1058792.210927] header_assemble with pid=5642 (5642) Sep 30 19:58:25 server kernel: [1058792.210929] CIFSSMBRead() try small_smb_init_with_pid()=0 with pid=5642 Sep 30 19:58:25 server kernel: [1058792.211234] CIFSSMBRead() try SendReceive2()=0 Sep 30 19:58:25 server kernel: [1058792.211237] cifs_read try CIFSSMBRead=0 with pid=5642 (5642) Sep 30 19:58:25 server kernel: [1058792.211254] cifs_readpages end cycle total_read=0 Sep 30 19:58:25 server kernel: [1058792.211832] header_assemble with pid=5643 (5643) Sep 30 19:58:25 server kernel: [1058792.212424] header_assemble with pid=5643 (5643) Sep 30 19:58:25 server kernel: [1058792.212429] CIFSSMBOpen() try small_smb_init_with_pid()=0 with pid=5643 Sep 30 19:58:25 server kernel: [1058792.213345] CIFSSMBOpen() try SendReceive()=0 Sep 30 19:58:25 server kernel: [1058792.213364] header_assemble with pid=5643 (5643) Sep 30 19:58:25 server kernel: [1058792.213851] header_assemble with pid=5642 (5642) Sep 30 19:58:25 server kernel: [1058792.214800] header_assemble with pid=5642 (5642) Sep 30 19:58:25 server kernel: [1058792.215957] header_assemble with pid=5642 (5642) ------ Пауза во время sleep() ------ Sep 30 19:58:30 server kernel: [1058797.213937] header_assemble with pid=5643 (5643) Sep 30 19:58:30 server kernel: [1058797.214415] cifs_readpages start cycle Sep 30 19:58:30 server kernel: [1058797.214426] header_assemble with pid=5643 (5642) Sep 30 19:58:30 server kernel: [1058797.214428] CIFSSMBRead() try small_smb_init_with_pid()=0 with pid=5643 Sep 30 19:58:30 server kernel: [1058797.214825] CIFSSMBRead() try SendReceive2()=0 Sep 30 19:58:30 server kernel: [1058797.214828] cifs_read try CIFSSMBRead=0 with pid=5643 (5642) Sep 30 19:58:30 server kernel: [1058797.214848] header_assemble with pid=5643 (5642) Sep 30 19:58:30 server kernel: [1058797.214849] CIFSSMBRead() try small_smb_init_with_pid()=0 with pid=5643 Sep 30 19:58:30 server kernel: [1058797.215169] CIFSSMBRead() try SendReceive2()=0 Sep 30 19:58:30 server kernel: [1058797.215171] cifs_read try CIFSSMBRead=0 with pid=5643 (5642) Sep 30 19:58:30 server kernel: [1058797.215187] cifs_readpages end cycle total_read=0 Sep 30 19:58:30 server kernel: [1058797.215271] header_assemble with pid=5642 (5642) Sep 30 19:58:30 server kernel: [1058797.215576] header_assemble with pid=5643 (5642) Второй лог исполенения: Sep 30 19:59:40 server kernel: [1058866.506209] header_assemble with pid=5656 (5656) Sep 30 19:59:40 server kernel: [1058866.507005] header_assemble with pid=5656 (5656) Sep 30 19:59:40 server kernel: [1058866.507008] CIFSSMBOpen() try small_smb_init_with_pid()=0 with pid=5656 Sep 30 19:59:40 server kernel: [1058866.507659] CIFSSMBOpen() try SendReceive()=0 Sep 30 19:59:40 server kernel: [1058866.508300] header_assemble with pid=5657 (5657) Sep 30 19:59:40 server kernel: [1058866.509363] header_assemble with pid=5657 (5657) Sep 30 19:59:40 server kernel: [1058866.509367] CIFSSMBOpen() try small_smb_init_with_pid()=0 with pid=5657 Sep 30 19:59:40 server kernel: [1058866.510170] CIFSSMBOpen() try SendReceive()=0 Sep 30 19:59:40 server kernel: [1058866.510186] header_assemble with pid=5657 (5657) Sep 30 19:59:40 server kernel: [1058866.511117] header_assemble with pid=5656 (5656) Sep 30 19:59:40 server kernel: [1058866.511425] header_assemble with pid=5656 (5656) Sep 30 19:59:40 server kernel: [1058866.511691] header_assemble with pid=5656 (5656) ------ Пауза во время sleep() ------ Sep 30 19:59:45 server kernel: [1058871.510995] header_assemble with pid=5657 (5657) Sep 30 19:59:45 server kernel: [1058871.511530] header_assemble with pid=5656 (5656) Sep 30 19:59:45 server kernel: [1058871.511833] header_assemble with pid=5657 (5656) В общем нужно рыть дальше...
В предложенном последнем тесте явно закралась ошибка: if (flk.l_type = F_UNLCK) printf("file locked by %d\n",flk.l_pid); else printf("file not locked\n"); мне кажется имелось ввиду if (flk.l_type != F_UNLCK) .
Да это была ошибка... Так что результаты тестов нужно пересмотреть...
По результатам http://bugs.etersoft.ru/show_bug.cgi?id=4341 в котором я задавал вопросы и сам пытался на них ответить, появилось решение... вместо разламывания nounix стало очевидным починка forcemand... Приводимый здесь патч для 2.6.30 должен позволять нормальную работу для wine, если для шары (в smb.conf) выставить один из параметров: posix locking = false blocking locks = false Да, и, конечно, глобальное отключение unix extensions не требуется и даже возбраняется... Нельзя отключать unix extensions.
Created attachment 1333 [details] Simple wine hacks for CIFS with mandatory locking only Привожу упрощённый патч (который вроде бы ничего не ломает). Этот патч решает некоторые проблемы при монтировании с forcemand.
Created attachment 1334 [details] Test for double open() of file and fail for read() after closing for one of fd Привожу тест, который выявляет проблему на текущем forcemand. Проблема состоит в отказе чтения после двойного открытия блокирования и последующего закрытия одного из файловых дескрипторов: $ ./raw6 start 20680 server start 20681 server open for 5 server second open for 6 server close 6 server send 5 server file not locked fd received=5 (len=1) file 5 locked by 20680 read failed on 5 (Permission denied) done Приводимый чуть ранее упрощённый патч решает эту проблему: $ ./raw6 start 19953 server start 19954 server open for 5 server second open for 6 server close 6 server send 5 server file not locked fd received=5 (len=1) file 5 locked by 19953 done
Резюмирую проблему. Для отключения сброса блокировок после закрытия файла необходимо выставить параметр шары: posix locking = false На текущий момент стоит монтировать с параметром noperm,forcemand Связка noperm,forcemand,direct ведёт себя нестабильно и, если где-то требуется, то эти случаи прошу указать отдельно - будем лечить по частям... PS: тестовый вариант модуля cifs собран на atlant, для шары //cellar/sharewine/ выставлен параметр "posix locking = false" - прошу тестировать... Нужно проверить VVS и 1С.
> PS: тестовый вариант модуля cifs собран на atlant, > для шары //cellar/sharewine/ выставлен параметр "posix > locking = false" - прошу тестировать... Нужно > проверить VVS и 1С. VVS совместно работают. 1С 7.7 вылетает, если в базу уже вошла другая 1С-ка.
(In reply to comment #18) > VVS совместно работают. 1С 7.7 вылетает, если в > базу уже вошла другая 1С-ка. > Так, давайте разбираться... Правда это уже будет другая бага наверное... Текущая версия модуля не сильно отличается от последнего релиза и ничего известного не ломает. У меня создаётся устойчивое впечатление, что работа 1С сломана... Укажите, если можете, с какими параметрами монтирования, какими опциями для шары smb.conf 7.7 вообще работала и работает сейчас (повторите сначала с текущим модулем, потом вернём исходный от 4.8.5) для etercifs-4.8.5? Я, конечно, предполагаю текущее окружение на atlant.
(In reply to comment #19) > У меня создаётся устойчивое впечатление, > что работа 1С сломана... > Укажите, если можете, с какими параметрами > монтирования, какими опциями для шары smb.conf > 7.7 вообще работала и работает сейчас С каким smb.conf 1С 7.7 работала раньше, я точно не знаю. Менял их только один раз, когда ты посоветовал отключить unix extensions. > (повторите сначала с текущим модулем, потом > вернём исходный от 4.8.5) для etercifs-4.8.5? Я, > конечно, предполагаю текущее окружение на > atlant. С текущими настройками на cellar вторая 1С-ка вылетает и с новым модулем, и с etercifs-4.3.8-alt5. Монтировал с noperm,forcemand.
> С текущими настройками на cellar вторая 1С-ка > вылетает и с новым модулем, и с etercifs-4.3.8-alt5. > Монтировал с noperm,forcemand. 1С-ки запускались в разных WINEPREFIX и для работы с базой использовали разные директории, в которые была смонтирована одна и та же шара. winelocktest в такой конфигурации сообщает о том, что в некоторых случаях не удаётся открыть файл. Если вырезать сообщения вида Test failed: Windows 95 sets GetLastError() = ERROR_SHARING_VIOLATION and Windows XP GetLastError() = 0, but now it is 4. indexes = 1[2, 3] - 2[2, 3] modes = 40000000/3/40000000/3 то картина такая: G_R G_R G_R G_W G_W G_W G_R|W G_R|W G_R|W S_R S_W S_R|W S_R S_W S_R|W S_R S_W S_R|W G_R FVL F. FVL F. F. F. F. F. F. S_R G_R F. F. F. FVL F. FVL F. F. F. S_W G_R FVL F. FVL FVL F. FVL FVL F. FVL S_R|W G_W F. FVL FVL F. F. F. F. F. F. S_R G_W F. F. F. F. Fo Fo F. F. F. S_W G_W F. FVL FVL F. Fo Fo F. Fo Fo S_R|W G_R|W F. F. FVL F. F. F. F. F. F. S_R G_R|W F. F. F. F. F. Fo F. F. F. S_W G_R|W F. F. FVL F. F. Fo F. F. Fo S_R|W
(In reply to comment #20) > (In reply to comment #19) > > У меня создаётся устойчивое впечатление, > > что работа 1С сломана... > > Укажите, если можете, с какими параметрами > > монтирования, какими опциями для шары smb.conf > > 7.7 вообще работала и работает сейчас > > С каким smb.conf 1С 7.7 работала раньше, я точно > не знаю. Менял их только один раз, когда ты > посоветовал отключить unix extensions. Очень жаль, unix extensions не стоит отключать, без них у нас пока ничего не работает... > > (повторите сначала с текущим модулем, потом > > вернём исходный от 4.8.5) для etercifs-4.8.5? Я, > > конечно, предполагаю текущее окружение на > > atlant. > > С текущими настройками на cellar вторая 1С-ка > вылетает и с новым модулем, и с etercifs-4.3.8-alt5. > Монтировал с noperm,forcemand. > Это я уже понял... Я вернул исходный модуль etercifs-4.3.8 на atlant. Ты помнишь, что я вчера подменил исходники etercifs для ядра 2.6.30? Кстати, тестирование проводилось только на нём? Давайте, когда ведём речь о проведении теста всегда указывать на каких машинах, с какими модулями (здесь важна версия ядра, а для старых ядер и версия дистрибутива), параметрами монтироования и на каких настройках сервера оно проводилось (эту связку я называю рабочей конфигурацией). Иначе вести речь о тестировании вообще бессмысленно - мы не знаем, что тестируем. В общем, нужно проверить работу 1С теперь уже с на исходной версии модуля и понять, способны ли мы вообще запустить 1С 7.7 на текущих выпусках Wine+Cifs в какой-либо конфигурации. В данном случае зафиксированы - клиент atlant - Sisyphus - 2.6.30-std-def-alt13 + etercifs-4.3.8-alt5 + wine-etersoft-1.0.11-alt9 + wine-etersoft-sql-1.0.11-alt5 - сервер cellar - Sisyphus - 2.6.27-ovz-smp-alt7 + samba-3.0.33-alt4 (здесь стоит smb.conf добавить) Добиться хотим работоспособности 1С 7.7 путём - подбора параметров монтирования: noperm,forcemand noperm,forcemand,direct noperm,forcemand,direct,brl .... - указания и комментирования флага posix locking = false в smb.conf (сейчас выставлен для //cellar/sharewine) Я полагаю получить ответ, способны ли мы, в заданных ограничениях, путём подбора параметров на текущих выпусках WINE+CIFS получить рабочий 1C 7.7 (желательно, с проверкой на всех рабочих базах). Далее, хотелось бы уточнить, пересекаются ли рабочие конфигурации (или настройки) для 1С 7.7 (если он вообще найдутся) с рабочими настройкам для VVS.
(In reply to comment #21) > > С текущими настройками на cellar вторая 1С-ка > > вылетает и с новым модулем, и с etercifs-4.3.8-alt5. > > Монтировал с noperm,forcemand. > > 1С-ки запускались в разных WINEPREFIX и для > работы с базой использовали разные > директории, в которые была смонтирована > одна и та же шара. winelocktest в такой Не понимаю причём тут разные директории, в которые была смонтирована одна и та же шара. Это имеет значение для winelocktest. > конфигурации сообщает о том, что в Я уже приводил, какие параметры значимы для проверки рабоче конфигурации. Это проводилось на текущей связке cellar+atlant? Модуль был с моим патчем (я так понимаю, что да..)? Если так, то проверьте теперь без него... > некоторых случаях не удаётся открыть файл. > Если вырезать сообщения вида > Test failed: Windows 95 sets GetLastError() = ERROR_SHARING_VIOLATION and > Windows XP GetLastError() = 0, but now it is 4. > indexes = 1[2, 3] - 2[2, 3] > modes = > 40000000/3/40000000/3 > то картина такая: ...... По моему, вчера эта ошибка уже возникала и выяснилось, что это проблема wine. У меня winelocktest проходит. Давайте выяснять в чём разница.
> Это я уже понял... Я вернул исходный модуль > etercifs-4.3.8 на atlant. Ты помнишь, что я вчера > подменил исходники etercifs для ядра 2.6.30? > Кстати, тестирование проводилось только на > нём? Тестировалось с модулем, который стоял и с модулем, который собирался при запуске сервиса после установки etercifs-4.3.8-alt5 (имеющийся etercifs.ko я перед этим переместил).
(In reply to comment #23) > (In reply to comment #21) > > > С текущими настройками на cellar вторая 1С-ка > > > вылетает и с новым модулем, и с etercifs-4.3.8-alt5. > > > Монтировал с noperm,forcemand. > > > > 1С-ки запускались в разных WINEPREFIX и для > > работы с базой использовали разные > > директории, в которые была смонтирована > > одна и та же шара. winelocktest в такой > > Не понимаю причём тут разные директории, в > которые была смонтирована одна и та же > шара. Это имеет значение для winelocktest. > > > конфигурации сообщает о том, что в > > Я уже приводил, какие параметры значимы для > проверки рабоче конфигурации. > Это проводилось на текущей связке cellar+atlant? > Модуль был с моим патчем (я так понимаю, что > да..)? Если так, то проверьте теперь без > него... Да, на atlant+cellar. Проверялось с тем модулем, который стоял, и с тем, что собирается после установки rpm-ки. > По моему, вчера эта ошибка уже возникала и > выяснилось, что это проблема wine. У меня > winelocktest проходит. Давайте выяснять в чём > разница. В том выводе, который ты мне показывал вчера, также присутствуют Fo, что означает, что в некоторых случаях файлы не открываются и соответственно нельзя считать, что winelocktest проходит. Это проблема etercifs, а не wine, так как её можно увидеть и на простых тестах вроде такого: #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #define FILENAME "test_file" #define FILE_SHARE_READ 1 #define FILE_SHARE_WRITE 2 int main() { int fd[2]; fd[0] = open(FILENAME, O_RDWR | (((~FILE_SHARE_READ | FILE_SHARE_WRITE) & 7) << 21), 0666); if (fd[0] < 0) { perror("open(1)"); return 1; } fd[1] = open(FILENAME, O_RDWR | (((~(FILE_SHARE_READ | FILE_SHARE_WRITE)) & 7) << 21), 0666); if (fd[1] < 0) { perror("open(2)"); } else { puts("OK"); close(fd[1]); } close(fd[0]); return 0; }
В приведённом выше тесте ошибка, должно быть так: fd[0] = open(FILENAME, O_RDWR | (((~(FILE_SHARE_READ | FILE_SHARE_WRITE)) & 7) << 21), 0666); вместо fd[0] = open(FILENAME, O_RDWR | (((~FILE_SHARE_READ | FILE_SHARE_WRITE) & 7) << 21), 0666); Так что из-за чего в некоторых случаях не открываются файлы, ещё надо разобраться.
(In reply to comment #25) > (In reply to comment #23) > > (In reply to comment #21) > > > > С текущими настройками на cellar вторая 1С-ка > > > > вылетает и с новым модулем, и с etercifs-4.3.8-alt5. > > > > Монтировал с noperm,forcemand. > > > > > > 1С-ки запускались в разных WINEPREFIX и для > > > работы с базой использовали разные > > > директории, в которые была смонтирована > > > одна и та же шара. winelocktest в такой > > > > Не понимаю причём тут разные директории, в > > которые была смонтирована одна и та же > > шара. Это имеет значение для winelocktest. > > > > > конфигурации сообщает о том, что в > > > > Я уже приводил, какие параметры значимы для > > проверки рабоче конфигурации. > > Это проводилось на текущей связке cellar+atlant? > > Модуль был с моим патчем (я так понимаю, что > > да..)? Если так, то проверьте теперь без > > него... > > Да, на atlant+cellar. Проверялось с тем модулем, > который стоял, и с тем, что собирается после > установки rpm-ки. > А я подменял как раз тот архив, из которого собираются модули в rpm-ке, а не подсовывал etercifs.ko вручную, после ручной же сборки... Тогда бы мне пришлось на это потратьишь больше времени... А так подменил архив в каталоге: /usr/share/etercifs/sources (старый переимновал с префиксом 'original.') и выполнил: # service etercifs build && service etercifs restart Так, что проверял ты с моим патчем... > > По моему, вчера эта ошибка уже возникала и > > выяснилось, что это проблема wine. У меня > > winelocktest проходит. Давайте выяснять в чём > > разница. > > В том выводе, который ты мне показывал > вчера, также присутствуют Fo, что означает, > что в некоторых случаях файлы не > открываются и соответственно нельзя Не-не-не... это как раз был мой тест на atlant'е, локально у меня ошибок нет. > считать, что winelocktest проходит. Это проблема > etercifs, а не wine, так как её можно увидеть и на > простых тестах вроде такого: > > #include <stdio.h> ... Я помню этот тест у меня всё это чинилось... последний вариант модуля таких ошибок уже не допускал... Я же там два разных варианта модулей пробовал... Первый глючил на таком простом тесте, как двойное открытие файла, а второй уже нет...
> > Да, на atlant+cellar. Проверялось с тем модулем, > > который стоял, и с тем, что собирается после > > установки rpm-ки. > > > > А я подменял как раз тот архив, из которого > собираются модули в rpm-ке, а не подсовывал > etercifs.ko вручную, после ручной же сборки... > Тогда бы мне пришлось на это потратьишь > больше времени... А так подменил архив в > каталоге: > /usr/share/etercifs/sources > (старый переимновал с префиксом 'original.') > и выполнил: > # service etercifs build && service etercifs restart > > Так, что проверял ты с моим патчем... Я думал, что этот архив перезаписывается при установке rpm-ки. С тем модулем, который загружен на atlant сейчас, 1С также вылетает.
Created attachment 1335 [details] smb.conf с cellar
Так, с 1С 7.7 проблем нет. На atlant стояла лицензия с COUNT_LICENSE=1 и поэтому две 1С-ки не работали.
Забавно... В общем, всё понятно... Непонятно как быть с упрощённым патчиком - он ведь даже исправляет кое-что... Но нужно проверить - вдруг чего ломает ;)
Created attachment 1336 [details] smb.conf с cellar (2.6.27-ovz-smp-alt7) На atlant (2.6.30-std-def-alt13) с патченным и оригинальным etercifs-4.3.8-alt5 //cellar/sharewine монтировался с noperm,forcemand Два VVS совместно работают. Две 1C 7.7 из разных wineprefix могут зайти в одну базу, видят друг друга в мониторе пользователей. Но при повторном входе в базу выводится сообщение о том, что программа была завершена аварийно.
