Bug 4290

Да, проблема с блокировками есть. При совместной работе 1С77 с atlant(2.6.30-std-def-alt10 + etercifs 4.3.8 + 1.0.11 sql eter8/eter3) и cellar(2.6.27-ovz-smp-alt7 + etercifs 4.3.8 + 1.0.11 sql eter8/eter3) пользователи не видят друг друга в мониторе пользователей (такая проблема уже была, см. баг 4118).

(In reply to comment #1)
> Да, проблема с блокировками есть. При
> совместной работе 1С77 с atlant(2.6.30-std-def-alt10 +
> etercifs 4.3.8 + 1.0.11 sql eter8/eter3) и cellar(2.6.27-ovz-smp-alt7 +
> etercifs 4.3.8 + 1.0.11 sql eter8/eter3) пользователи не
> видят друг друга в мониторе пользователей
> (такая проблема уже была, см. баг 4118).
Желательно упростить условия, проверяя на одной машине, чтобы вывести из подозреваемых версию ядра (и etercifs соответственно).
Если у нас воспроизводится, стоит проверить на 1.0.10, чтобы понять время внесения проблем.
Поскольку winelocktest не показывает проблему, надо понять, что в нём усовершенствовать.

Проблема не воспроизводится с cellar (2.6.27-ovz-smp-alt7 +
> etercifs 4.3.8 + 1.0.11 sql eter8/eter3) и lin-test (2.6.28-15-generic + etercifs 4.3.8 + 1.0.11 sql eter8/eter3). По-видимому, проблема только на новых ядрах.

На 2.6.30-std-def-alt10 сбрасывается блокировка после закрытия файлового дескриптора. Сделал тестовую программу для воспроизведения проблемы: wine-etersoft-devel/cifs/lincifs

(In reply to comment #4)
> На 2.6.30-std-def-alt10 сбрасывается блокировка
> после закрытия файлового дескриптора.
> Сделал тестовую программу для
> воспроизведения проблемы:
> wine-etersoft-devel/cifs/lincifs
> 

Ну, так это верно, если сервер - Samba. Тут нужно отключать unix расширения, чтобы на самбе это перестало работать...

Патч для сбрасывания блокировок после закрытия файлового дескриптора на CIFS, который убрали, исходно был для Windows-сервера, который не умеет unix-extensions.

> Ну, так это верно, если сервер - Samba.

Но WINE при таком поведении блокировок корректно работать не сможет.

> Ну, так это верно, если сервер - Samba.

Насколько я понимаю, samba монтируется с -t smbfs, а в данном случае всё-таки -t cifs.

(In reply to comment #7)
> > Ну, так это верно, если сервер - Samba.
> 
> Насколько я понимаю, samba монтируется с -t smbfs,
> а в данном случае всё-таки -t cifs.
> 

Вы неправильно понимаете. Samba как раз и работает по протоколу CIFS. А то, что раньше драйвер в ядре назывался smbfs, для ранних версий протокола, здесь уже не важно.

> Ну, так это верно, если сервер - Samba. Тут
> нужно отключать unix расширения, чтобы на
> самбе это перестало работать...

С отключенными unix extensions блокировка при закрытии дескриптора не сбрасывается. Мониторы пользователей в 1С 7.7 работают нормально.

А у нас в документации где-нибудь про unix extensions написано?

Когда я узнал, что нужно оторвать POSIX поведение, которого мы ранее отдельно добивались, я уже полагал, что придётся отключать unix-extensions и думал, что при таком требовании те, кто внесут соответствующие изменения внесут поправку в документацию.

Но теперь я так понимаю, что новый etercifs должен был не просто отключить исправления, но и автоматом выставить отключение unix-extensions.

Вообще, это не хорошо, потому что без unix-extensions не будут работать символические ссылки и другие unix-штуки. Плохо тут ещё и то, что это опция включается глобально - не может быть выставлена для отдельных шар.

> Вообще, это не хорошо, потому что без
> unix-extensions не будут работать символические
> ссылки и другие unix-штуки. Плохо тут ещё и то,
> что это опция включается глобально - не
> может быть выставлена для отдельных шар.

А можно ли сделать так, чтобы сброс блокировок при закрытии не производился только для тех файлов, которые открыты с опциями, передающими флаги вроде SHARE_READ, и чтобы это делалось независимо от unix extensions?

(In reply to comment #10)
> Когда я узнал, что нужно оторвать POSIX
> поведение, которого мы ранее отдельно
> добивались, я уже полагал, что придётся
> отключать unix-extensions и думал, что при таком
> требовании те, кто внесут соответствующие
> изменения внесут поправку в документацию.
Не вижу никакой связи между нашим патчем на POSIX-поведение и работой Unix-extensions на сервере. Если ты видел какие-то последствия отмены этого патча, можно было о них сообщить.

1C 7.7, запущенные на atlant (2.6.30-std-def-alt10 +
etercifs 4.3.8 + 1.0.11 sql eter8/eter3) и Debian 5.0.2 в VirtualBox (2.6.26-2-686 + etercifs 4.3.8 + 1.0.11 sql eter8/eter3), в мониторе пользователей друг друга видят (unix extensions при этом отключены).

(In reply to comment #11)
> > Вообще, это не хорошо, потому что без
> > unix-extensions не будут работать символические
> > ссылки и другие unix-штуки. Плохо тут ещё и то,
> > что это опция включается глобально - не
> > может быть выставлена для отдельных шар.
> 
> А можно ли сделать так, чтобы сброс
> блокировок при закрытии не производился
> только для тех файлов, которые открыты с
> опциями, передающими флаги вроде SHARE_READ, и
> чтобы это делалось независимо от unix extensions?
> 

Принципиально такой костыль возможен, но технически, мне этот вариант совершенно не нравится. К тому же для этого необходимо патчить самбу.

Вообще это какое-то странное предложение. Зачем делать такое труднопроверяемое решение? Это может вылезти боком в другом месте...

Я так понимаю, что новый Wine требует отключения unix-extesions вот и всё... Это цена за новые фишки, которые получились в такой реализации... Вообще я не могу отслеживать эту часть, поскольку технические детали развития wine особо не обсуждаются... Выбор этого технического решения на обсуждение не выносился... 

Очень жаль, что мы нарвались на эту проблему в таком виде и я вовремя её не осознал, чтобы предупредить... Всё же было ясно... С другой стороны, куда смотрели разработчики и как прохлопали регрессию в релизе?

(In reply to comment #12)
> (In reply to comment #10)
> > Когда я узнал, что нужно оторвать POSIX
> > поведение, которого мы ранее отдельно
> > добивались, я уже полагал, что придётся
> > отключать unix-extensions и думал, что при таком
> > требовании те, кто внесут соответствующие
> > изменения внесут поправку в документацию.
> Не вижу никакой связи между нашим патчем на
> POSIX-поведение и работой Unix-extensions на сервере.
> Если ты видел какие-то последствия отмены
> этого патча, можно было о них сообщить.
> 

А принципиальной связи и нет... и последствий я не видел... Я сетую на то, что не предупредил, что если закладываться на отсутствие сброса блокировок после закрытия файла, то этот патч оторвёт такое поведение только для Windows-шар, поскольку для Linux-шар - этим занимается самба...

У меня вертелась идея спросить об этом, но сорвалась и я не смог её сразу сформулировать. Хотя вопрос остаётся прежним. Как быть с Linux-шарами, отключать unix-extesions?

(In reply to comment #14)
...
> Принципиально такой костыль возможен, но
> технически, мне этот вариант совершенно не
> нравится. К тому же для этого необходимо
> патчить самбу.
Так делать не будем.
...

> Я так понимаю, что новый Wine требует
> отключения unix-extesions вот и всё... Это цена за
Собственно, с чего мы начали 3 года назад.

> новые фишки, которые получились в такой
> реализации... Вообще я не могу отслеживать
Какие фишки имеются в виду?

> эту часть, поскольку технические детали
> развития wine особо не обсуждаются... Выбор
> этого технического решения на обсуждение
> не выносился...
Ну вы можете тут обсудить подробности решения конечно...
Мне всегда казалось, что extensions - это расширения, а они оказываются
меняют такую фундаментальную вещь, как сброс блокировок.

Думаю, пока выхода, кроме nounix при монтировании, нет.
По крайней мере пока мы не научимся получать текущий режим работы CIFS - с Unix extensions или без.

...
> С другой стороны, куда смотрели
> разработчики и как прохлопали регрессию в
> релизе?
Это вопрос о том, а как её можно заметить, эту регрессию? Уже есть понятный способ воспроизведения?

> Я сетую на то, что
> не предупредил, что если закладываться на
> отсутствие сброса блокировок после
> закрытия файла, то этот патч оторвёт такое
> поведение только для Windows-шар, поскольку
> для Linux-шар - этим занимается самба...
Да, вот это конечно очень плохо. Нам и в голову не могло прийти, что для Linux они сделали по-другому. В общем эти Unix extensions - хак, который добавляет проблем, и непонятно зачем улучшает совместимость SAMBA с Linux, при том что SAMBA толком для Linux никогда не разрабатывалась.

> сформулировать. Хотя вопрос остаётся
> прежним. Как быть с Linux-шарами, отключать
> unix-extesions?
Это вопрос строки в документации и конфига etermount.

Кстати, хочу обратить внимание на то, что по крайней мере на ядрах 2.6.27 и 2.6.28 блокировки не сбрасываются и при включенных unix extensions.

> Вообще это какое-то странное предложение.

Просто это меньшее отклонение от POSIX, чем просто запрет на сброс блокировок во всех случаях.

> Я так понимаю, что новый Wine требует
> отключения unix-extesions вот и всё...

Вроде бы в отношении CIFS в WINE ничего принципиально в последнее время не менялось.

> Вообще я не могу отслеживать
> эту часть, поскольку технические детали
> развития wine особо не обсуждаются... Выбор
> этого технического решения на обсуждение
> не выносился... 

http://bugs.etersoft.ru/show_bug.cgi?id=4132

Мы проверили работу последней сборки (WINE@Etersoft 1.0 SQL 1.0.11-eter8/3) c цифсом 4.3.8. Вне зависимости от параметра unix extensions вроде на первый взгляд работает (детально не тестировали, проверили только основную ошибку возникающюю при проведении).
При этом, опять-же вне зависимости от данного флага, предыдущая сборка даёт повторяемость ошибки.

Проверка делалась на 26 ядре из репозитория Деб5.

> По крайней мере пока мы не научимся
> получать текущий режим работы CIFS - с Unix
> extensions или без.

Мгм. Конечно, это дело разработчиков, но к примеру у нас активно используется шара, на которой фактически хранится большая часть информации пользователей, и которая при отключенных extensions м-м-м мягко говоря работает далеко не так как надо. Т.о. получается, что Вы таким образом поставите перед выбором - либо непонятки с 1С, либо непонятки с другими шарами?

Повторю своё предложение собрать Вам VM-машину - нашего типового клиента, ну, скажем, с нашим типовым 18 ядром (которых у нас большинство), и, соответственно, типовой наш самба-сервер, для тестирования.

С уважением,
Алексей (ЛЭПКОС)

(In reply to comment #18)
> Мы проверили работу последней сборки
> (WINE@Etersoft 1.0 SQL 1.0.11-eter8/3) c цифсом 4.3.8. Вне
> зависимости от параметра unix extensions ...

А соответственно и независимо от nounix - параметра монтирования шары


(Возможно, что дальнейшее не в эту тему)
Так же в ходе тестирования обнаружился следующий баг:
При использовании параметра direct при монтировании шары перестает сохранять документы опенофис (3.1.1), выдавая "Невозможно создать резервную копию".

Есть ещё баги с корзиной KDE при удалении с шары и с возникающими файлами типа "cifs####"(Вообще призрачно).

C уважением,
Олег Волков (Лэпкос)