Bug 9444

Машины в  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,ошибок нет, блокировки работают.

Закрываю.