Установлены WINE@Etersoft Network 2.1.2/2.1.0-eter17/3 и etercifs 5.4.7 Смонтирована шара с БД для 1с77. При запуске конфигурации 1с77 на fedora - ошибка загрузки метаданных.На windows работает корректно. Подробности тут:https://bugs.etersoft.ru/show_bug.cgi?id=7100#c58 Также узнать подробности можно у anton@im.etersoft.ru
Машины в vbox: [T]Fedora_17x64 (по техническим причинам в данный момент в группе sql) [T]Windowx XP Sv Снимки на обеих "9444"
Разобрался с проблемой. Сервер по разному реагирует на вызов query path info (unix) при использовании различных протоколов аутентификации. В нашем случае произошёл переход с NTLM на NTLMSSP, что изменило реакцию сервера на данный запрос. Конкретная причина, изменившая поведение сервера при механизме аутентификации NTLMSSP пока не выяснена. Задал вопрос в рассылку cifs. Для клиента проблему можно решить следующим образом - указать опцию монтирования sec=ntlm или sec=ntlmv2.
У клиента возникла новая проблема. Необходимо воспроизвести у нас.
(В ответ на comment #3) -\\- > <piastryyy> всё тоже самое только добавляется эта опция sec=ntlm Машины те же: > [T]Fedora_17x64 (по техническим причинам в данный момент в группе sql) > [T]Windowx XP Sv > Снимки на обеих "9444" Строка монтирования: mount -t cifs //192.168.4.28/sharewine /mnt/cifs -o user=guest,pass=123,sec=ntlm,nolock [sharewine] path = /var/local/share public = yes force user = guest force group = users writable = yes guest ok =no browseable = yes #posix locking = false create mask = 0775 create mask = 0664 directory mask = 0777 force directory mask = 0777 case sensitive = no .. default case = lower preserve case = no short preserve case =no При запуске конфигурации от разных пользователей ошибки метаданных не возникает. p.s. В настройках федоры выставила везде русский язык, потому что без этого стартовое окно запускалось с ?????? вместо текста и конфигурация не загружалась с ошибкой,которую нельзя было прочесть. На обеих машинах снимки 9444-1
при строке монтирования mount -t cifs //192.168.4.28/sharewine /mnt/cifs -o user=guest,pass=123,sec=ntlm Всегда под windows в 1с входит пользователь "Новый2",под Федорой "Новый1". Если сначала запустить конфигурацию на Федоре, а потом на windows,то работа 1с корректна. Далее если на федоре 1с закрыть и попытаться запустить заново, то появится ошибка "программа была завершена аварийно, запустите в монопольном режиме", но при запуске в монопольном режиме возникает "ошибка блокировки данных, возможно данные используются другой задачей " Закрываю 1с на windows.Запускаю на федоре монопольно - работает. Запускаю на windows - ошибка блокировки данных. Воспроизводится. снимки 9444-2
если просто дописать опцию wine,то 1с на федоре не запускается совсем с ошибкой метаданных, и в монопольном режиме. На windows запускается корректно. Пересоздала базу - не помогло.
Опции монтирования клиента: mountopts="-fstype=cifs,sec=ntlm,rw,wine,noperm,nounix,nostrictsync,uid= ${username},gid=502"
mount -t cifs //192.168.4.28/sharewine /mnt/cifs -o sec=ntlm,rw,wine,noperm,nounix,nostrictsync,gid=502,user=guest,password=123 при и спользовании опции wine все же "ошибка загрузки метаданных" на fedora.
(В ответ на comment #8) > mount -t cifs //192.168.4.28/sharewine /mnt/cifs -o > sec=ntlm,rw,wine,noperm,nounix,nostrictsync,user=guest,password=123 > при и спользовании опции wine все же "ошибка загрузки метаданных" на fedora. В режиме конфигуратора загружается с обеих систем как положено (блокировки работают корректно). На windows конфигурация запускается корректно, на федоре - ошибка мета данных, причем не зависимо от опций. Подключла данную базу локально - запускается корректно.
При монтировании по cifs,как и ранее, (попробовала также etermount) возникает ошибка загрузки метаданных. Попробовала по nfs простой командой: mount //192.168.4.28/sharewine /mnt/cifs -o user=guest,pass=123 #mount //192.168.4.28/sharewine on /mnt/cifs type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,sec=ntlmssp,cache=strict,unc=\\192.168.4.28\sharewine,username=guest,domain=LOCALHOST,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.4.28,unix,posixpaths,serverino,acl,rsize=1048576,wsize=65536,actimeo=1) ошибки не возникает. попробовала с параметрами: # mount -t cifs //192.168.4.28/sharewine /mnt/cifs -onoperm,rw,username=guest,domain=LOCALHOST,sec=ntlm ошибки не возникает. Добавление параметра "wine" к последнему варианту возобновляет ошибку.
На более раннем ядре - 3.8.13-100.fc17.x86_64 + etercifs-5.4.7-eter1fedora.noarch - аналогично. На ядре 3.8 + etercifs-5.4.4-eter1fedora.noarch.rpm - аналогично.
убраны параметры: case sensitive = no oplocks = no short preserve case =no mount -t cifs //192.168.4.28/sharewine /mnt/cifs -o user=guest,pass=123,sec=ntlm,wine ошибки нет. но при этом подключаюсь под пользователем новый1 одновременно и с windows и с fedora. Причем этот активный пользователь виден дважды.
(В ответ на comment #12) > но при этом подключаюсь под пользователем новый1 одновременно и с windows и > с fedora. Причем этот активный пользователь виден дважды. Не зависимо от очередности систем. Ошибка блокировки данных,как и положено,возникает только в случае запуска 1с из-под конфигуратора.
Разбирались со Светой с воспроизведением проблемы.
Пересоздала базу. выполнила setwineshare права на базу guest:users 1.Windows-windows Подключаюсь с 2х машин windows под одним пользователем к базе под одним и тем же пользователем Новый 1,редактирую один и тот же документ одновременно,недоступна только запись,редактируемая в данный момент на другом клиенте(например,выбор сотрудника в первой строке списка "операции-журнал документов-авансовые отчеты"). Попробовала на 2х базах: 1SBdemoNEW и Test_base. Подключаюсь под разными пользователями: - аналогично. Конфигуратор можно запустить только под одним пользователем, при запуске второй копии - ошибка блокировки метаданных (как и положено). 2.windows-linux строка монтирования: mount -t cifs //192.168.4.28/sharewine /mnt/cifs -o user=guest,pass=123,sec=ntlm,wine а) Сначала запускаю 1с на linux , затем на windows под одним и тем же пользователем - ситуация аналогичная windows. б) Сначала windows потом linux - аналогично. 3.linux-linux (fedora - [svzhu]Altlinux6) etercifs-5.4.4-alt0.M60P.1 при запуске с Altlinux6 смонтированной конфигурации получаю первым делом ошибку: err:winediag:FILE_CreateFile failed to open L"\\??\\L:\\dir\\1SBDemoNEW\\1Cv7.LCK" because of insufficient access rights хотя права выставлены корректно, и такой файл не существует. Создала его вручную,конфигурация запустилась. Ситуация аналогичная windows.
в случае,когда бд находится на windows,с обеих машин windows также вхожу под одним и тем же пользователем.
Посмотрела как обстоят дела в бутылках - 1с77 и 1c82 - везде (одна из конфигураций - торговля и склад,к примеру ) можно под одним и тем же пользователем войти несколько раз и редактировать один документ. Но если войти под разными пользователями в одну и ту же базу, то документ редактировать одновременно нельзя - блокировки работают корректно. eter-2.1 1c77/1c77 1c82/1c82 WINE@Etersoft SQL 2.1.3/2.1.0-eter5/3
Обсудили со Светой дальнейший план действий. Конфигурация ядро 3.8 + этерцифс 5.4.4 согласно тестированию признана рабочей, что совпадает с тем, что описывает клиент. Далее тестирование необходимо провести в два шага: 1) обновить этерцифс до версии 5.4.7, проверить; 2) обновить ядро до версии 3.9, проверить.
>теперь надо проверить связки >3.8 + 5.4.7 >3.9 + 5.4.7 1) 3.8 + 5.4.7 [T]Fedora_17x64 [T]Windowx XP Sv Уснатовила cifs 5.4.7. mount -t cifs //192.168.4.28/sharewine /mnt/cifs -o user=guest,pass=123,sec=ntlm,wine 1с77 запускается без ошибок на обеих системах, не зависимо от очередности запуска (также одновременное редактирование одного документа из разных мест недоступно. Снимок на fedora "3.8+547" 2)3.9 + 5.4.7 В последовательности: fedora-windows - запускается корректно windows-fedora - не запускается: "ошибка при запуске журнала регистрации". Снимок на fedora "3.9 + 5.4.7"
(В ответ на comment #19) default case = lower preserve case = yes
(В ответ на comment #19) > >теперь надо проверить связки > >3.8 + 5.4.7 > >3.9 + 5.4.7 > > 1) 3.8 + 5.4.7 > > [T]Fedora_17x64 > [T]Windowx XP Sv > > Уснатовила cifs 5.4.7. > > mount -t cifs //192.168.4.28/sharewine /mnt/cifs -o > user=guest,pass=123,sec=ntlm,wine > > 1с77 запускается без ошибок на обеих системах, не зависимо от очередности > запуска (также одновременное редактирование одного документа из разных мест > недоступно. > Снимок на fedora "3.8+547" > > 2)3.9 + 5.4.7 > В последовательности: > fedora-windows - запускается корректно > windows-fedora - не запускается: "ошибка при запуске журнала регистрации". > Снимок на fedora "3.9 + 5.4.7" Таким образом, проблема возникает при переходе с ядра 3.8 и 3.9 на последнем акутальном etercifs-5.4.7. Начал изучать diff между ядрами.
Created attachment 2993 [details] diff -uNr sources/3.8 sources/3.9
Created attachment 2994 [details] git log v3.8..v3.9 -- fs/cifs
Продолжил изучать diff. Добавил diff и список коммитов в багу.
Обнаружил, что в ядре 3.9 ошибка STATUS_SHARING_VIOLATION транслируется в EBUSY, в то время как раньше было ETXTBSY. WINE транслирует EBUSY в STATUS_FILE_LOCK_CONFLICT, а ETXTBSY - STATUS_SHARING_VIOLATION. Исправил обратно в ядрах 3.9 и 3.11 и собрал в etercifs-5.4.8. Надо протестировать данную сборку.
(В ответ на comment #25) > Обнаружил, что в ядре 3.9 ошибка STATUS_SHARING_VIOLATION транслируется в > EBUSY, в то время как раньше было ETXTBSY. WINE транслирует EBUSY в > STATUS_FILE_LOCK_CONFLICT, а ETXTBSY - STATUS_SHARING_VIOLATION. Я так понял, что обсуждение изменения было здесь: http://www.spinics.net/lists/linux-cifs/msg07798.html А, в wine два варианта в sharing violation превращается: case ETXTBSY: case EAGAIN: set_error( STATUS_SHARING_VIOLATION ); break; Так нужно что-то решить глобально. Они молодцы, легко так исправили CIFS, чтобы всё сломалось. А неужели RECT не позволял выявить эту проблему? Мне не очень нравится что 20 часов по баге потрачено на поиск такого изменения кода. А неужели нельзя было протестировать с помощью winelocktest? 2svzhu: Если на какой-то системе появляется проблема, надо тестировать 1. у нас если проблема воспроизводится, 1. тестировать на предыдущей версии системы (ядра, программы) Нужно по возможности частную проблему клиента превратить в общее, не зависящее от дистрибутива клиента, и довести до конкретных версий. Я не понимаю, почему при воспроизведении проблемы полностью проигнорированы наши средства по тестированию файловых систем.
(В ответ на comment #26) > Я так понял, что обсуждение изменения было здесь: > http://www.spinics.net/lists/linux-cifs/msg07798.html > > А, в wine два варианта в sharing violation превращается: > case ETXTBSY: > case EAGAIN: set_error( STATUS_SHARING_VIOLATION ); break; > > Так нужно что-то решить глобально. Они молодцы, легко так исправили CIFS, > чтобы всё сломалось. В etercifs мы можем продолжать подменять, пока не станет ясно что-то со статусом флагов доступа в ядре, так как в случае принятие наших патчей для sharing violation будет отдельный новый код ошибки. > А неужели RECT не позволял выявить эту проблему? RECT не проверяет код возврата, он лишь проверяет была ошибка или нет. > Мне не очень нравится что 20 часов по баге потрачено на поиск такого > изменения кода. Из данных 20 часов половина времени была потрачена на обнаружение другой проблемы, появившейся в ядре 3.8 с переходом на новый механизм аутентификации по умолчанию. Другая половина потрачена на воспроизведение и локализацию второй проблемы с кодом ошибки. Данная бага посвящена проблеме у конкретного клиента. При выделении новой задачи, нужно создавать новую багу, чтобы не мешать всё в одно и не усложнять потом поиск истоков.
(В ответ на comment #25) > Обнаружил, что в ядре 3.9 ошибка STATUS_SHARING_VIOLATION транслируется в > EBUSY, в то время как раньше было ETXTBSY. WINE транслирует EBUSY в > STATUS_FILE_LOCK_CONFLICT, а ETXTBSY - STATUS_SHARING_VIOLATION. > > Исправил обратно в ядрах 3.9 и 3.11 и собрал в etercifs-5.4.8. Надо > протестировать данную сборку. Ядро 3.9.10-100.fc17.x86_64 etercifs-5.4.4-eter1fedora.noarch.rpm При выполнении build: make[1]: *** [/tmp/Etercifs.sxVxHBGp/kernel-source-etercifs-3.7-2.0/inode.o] Error 1 make: *** [_module_/tmp/Etercifs.sxVxHBGp/kernel-source-etercifs-3.7-2.0] Error 2 make: Leaving directory `/usr/src/kernels/3.9.10-100.fc17.x86_64' can't locate built module etercifs.ko CIFS kernel module status: WARNING!!! Kernel module etercifs is not loaded!
(В ответ на comment #28) > Ядро 3.9.10-100.fc17.x86_64 > etercifs-5.4.4-eter1fedora.noarch.rpm > CIFS kernel module status: > WARNING!!! Kernel module etercifs is not loaded! В тестинг оказалась старая версия cifs. etercifs 5.4.8-eter1fedora - устанавливается корректно. Ядро 3.9.10-100.fc17.x86_64 Программа работает корректно, не зависимо от очередности запуска windows-linux,ошибок нет, блокировки работают.
Закрываю.
