Шара располагается на линукс машине (cellar). Пытаюсь зайти с одной машины (lin-test) под разными пользователями. Первый заходит без проблем, при выборе и попытке зайти 2 пользователем выдается ошибка доступа у файлу. Лог с трайсом по +file прилагаю.
uname -r 2.6.25-std-def-alt9 Монтировал mount -t cifs //cellar/sharewine /mnt/cifs/ -o uid=guest,gid=guest,file_mode=0660,dir_mode=0770 linux-cifs-3.1
На данный момент основная проблема здесь.
(In reply to comment #1) > uname -r > 2.6.25-std-def-alt9 > > Монтировал mount -t cifs //cellar/sharewine /mnt/cifs/ -o > uid=guest,gid=guest,file_mode=0660,dir_mode=0770 > > linux-cifs-3.1 > см. http://bugs.etersoft.ru/show_bug.cgi?id=1153#c18 монтировали мы так: $ cifsmount //server/base ~/base -o user=guest Через симлинк ~/.wine/dosdevices/e: 1с получает доступ к базе.
*** This bug has been marked as a duplicate of bug 1153 ***
Просьба багу не закрывать как дублирующую, она посвящена конкретной проблеме, специально чтобы не отвлекаться в сторону.
В общем на пустой информационной базе, когда предлагается сделать её не из шаблона, а вручную... несколько пользователей подключаются и работают нормально... Возможно это искусственный тест... Но хотелось бы его подтвердить на cellar. Проверите? 300Мб база у меня не грузится даже на 1 клиенте... Хотелось бы получить базу поменьше, также шаблоны для создания этой баз, которые будут хоть что-то собой представлять... В общем, проблемы нескольких пользователей у меня не подтвердились. А вот проблемы загрузки больших баз выявились. Думаю стоит сделать набор тестовых разного объёма и конфигураций.
(In reply to comment #6) > 300Мб база у меня не грузится даже на 1 > клиенте... подтверждаю: вывод top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10614 kipruss 20 0 2602M 62M 35M R 99.4 3.2 4:50.13 1cv8.exe и так можно ждать Запуск из консоли: [kipruss@valhalla bin]$ ./1cv8.exe fixme:heap:HeapSetInformation 0xbd0000 0 0x33fb7c 4 fixme:rpc:alloc_serverprotoseq protseq "mswmsg" not supported fixme:rpc:alloc_serverprotoseq protseq "mswmsg" not supported fixme:gdi:ExtCreatePen Hatches not implemented и все... Запустил strace ./1cv8.exe В конце концов непрерывно бегут вот такие строчки: read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=97, events=POLLIN}], 1, -1) = 1 ([{fd=97, revents=POLLIN}]) read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=97, events=POLLIN}], 1, -1) = 1 ([{fd=97, revents=POLLIN}]) read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=97, events=POLLIN}], 1, -1) = 1 ([{fd=97, revents=POLLIN}]) read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=97, events=POLLIN}], 1, -1) = 1 ([{fd=97, revents=POLLIN}]) read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily unavailable)
Весь файл вывода out1: strace ./1cv8.exe > out 2>&1 head out -n 150000 > out1 даже чуть урезанный с конца более 7 Мб. Если нужно - перешлю. Вот последние строки перед началом кучи повторяющихся похожих строк указанного вида: open("/home/kipruss/.wine/dosdevices/e:/home/kipruss/base", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 97 fstat64(97, {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 fcntl64(97, F_SETFD, FD_CLOEXEC) = 0 getdents64(97, /* 9 entries */, 16384) = 272 close(97) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 writev(3, [{"\"\0\0\0H\0\0\0\0\0\0\0\0\0\0\300@\0\0\0\3\0\0\0\1\0\0\0P\0\0\0\0"..., 64}, {"\0\0\0\0\0\0\0\0\0\0\0\0"..., 12}, {"/home/kipruss/.wine/dosdevices/e:"..., 60}], 3) = 136 read(5, "\0\0\0\0\0\0\0\0\200\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [HUP INT USR1 USR2 ALRM CHLD IO], 8) = 0 write(3, "%\0\0\0\0\0\0\0\0\0\0\0\200\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\237\1\22\0P\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [HUP INT USR1 USR2 ALRM CHLD IO], NULL, 8) = 0 recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\200\4\0\0"..., 4}], msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {97}}, msg_flags=0}, 0) = 4 fcntl64(97, F_SETFD, FD_CLOEXEC) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 fstat64(97, {st_mode=S_IFREG|S_ISGID|0767, st_size=162538, ...}) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 _llseek(97, 162538, [162538], SEEK_SET) = 0 gettimeofday({1224058659, 556558}, NULL) = 0 time(NULL) = 1224058659 time(NULL) = 1224058659 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(3, "'\0\0\0\0\0\0\0\0\0\0\0\200\4\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 gettimeofday({1224058659, 556962}, NULL) = 0 time(NULL) = 1224058659 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 _llseek(97, 0, [0], SEEK_SET) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=97, events=POLLIN}], 1, -1) = 1 ([{fd=97, revents=POLLIN}]) read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=97, events=POLLIN}], 1, -1) = 1 ([{fd=97, revents=POLLIN}]) read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=97, events=POLLIN}], 1, -1) = 1 ([{fd=97, revents=POLLIN}]) read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=97, events=POLLIN}], 1, -1) = 1 ([{fd=97, revents=POLLIN}]) read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily unavailable)
Если подключать пустую базу, то работоспособность тоже какая-то мнимая, ибо если посмотреть в strace, то там будут такие повторяющиеся строки строки: rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(3, "{\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\0\0\0\0@"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\23\1\0\0\377\177\0\0'\0\377\377\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 read(82, 0x7c0c1b5c, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(82, 0x7c0c1b5c, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(10, 0x7c059864, 4096) = -1 EAGAIN (Resource temporarily unavailable) rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(3, "{\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\0\0\0\0@"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\23\1\0\0\377\177\0\0'\0\377\377\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 read(82, 0x7c0c1b5c, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(82, 0x7c0c1b5c, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(10, 0x7c059864, 4096) = -1 EAGAIN (Resource temporarily unavailable)
Из винды (виртуалбокс) зашел в базу кассиром. Причем ждал не больше 5 секунд. Конфигурация управление торговлей, редакция 10.3
Ещё информация: 0. Есть у меня некая база для 1с 8.0 1. Пытался я её конвертировать в 1с под wine - не получилось. 2. В винде все конвертируется и потом запускается 3. В Линуксе уже сконвертированную виндой базу открыть не получается (даже локально). Выводится сообщение от wine: Запись дампа Подождите пожалуйста! Выполняется сохранение информации об ошибке для возможности последующего анализа. Куда они сохраняются я не нашёл. Версии ПО совпадают с указанными тут: http://bugs.etersoft.ru/show_bug.cgi?id=1153#c18
Скопировал тестовую базу, присланную нам из Питера в локальный каталог - пытался открыть 1с под wine - не получилось. Симптомы аналогичны описанным мною выше: http://bugs.etersoft.ru/show_bug.cgi?id=2599#c7 и далее
Уточняю, что на локальной базе (Питерской) проблемы проявляются при вхождении Кассиром. Если зайти администратором, то работает. Пришлите базы, которые хотя бы локально точно работают. Возможно, у нас разные версии wine Итог (локальный): Выяснились две разные проблемы: 1. При нахождении базы на линуксовой шаре 1cv8.exe отжирает почти весь один процессор и не работает (см. http://bugs.etersoft.ru/show_bug.cgi?id=2599#c7 ) 2. Некоторые базы вешают 1с даже локально - см. http://bugs.etersoft.ru/show_bug.cgi?id=2599#c11
Константин, попробуйте протестировать так же, как монтировал Денис. Опции user и uid разные. Убедитесь что версии wine и linux-cifs у вас с Денисом одинаковые. Проблема у меня воспроизводилась и на демо-базе. Размер в данном случае значения не имеет. Так же проверьте как себя ведет смонтированный ресурс при использовании опции noperm, потому что я замечал различия в работе при явном указании владельца/группы и noperm.
(In reply to comment #14) > Константин, попробуйте протестировать так > же, как монтировал Денис. > Опции user и uid разные. > Убедитесь что версии wine и linux-cifs у вас с > Денисом одинаковые. > Проблема у меня воспроизводилась и на > демо-базе. Размер в данном случае значения > не имеет. > Так же проверьте как себя ведет > смонтированный ресурс при использовании > опции noperm, потому что я замечал различия в > работе при явном указании владельца/группы > и noperm. > Смонтировать так не получается из-за настроек самбы. Пишет: bad user name "guest" Пришлите настройки самбы для шары на компьютере cellar Напоминаю версии пакетов у нас: 1с - содержимое папки 1Cv81-8.1.11.67-Windows-i386 wine-1.0.9-alt24 libwine-1.0.9-alt24 linux-cifs-3.2-alt2 haspd-2.0-alt10 haspd-modules-2.0-alt10 wine-etersoft-sql-1.0.9-alt5
> Смонтировать так не получается из-за > настроек самбы. > Пишет: bad user name "guest" > Пришлите настройки самбы для шары на > компьютере cellar у Вас нет доступа к cellar? [global] <skip> security = share <skip> [share] path = /var/share public = yes writable = yes guest ok = yes [sharewine] path = /var/local/share public = yes force user = wine force group = winetester writable = yes guest ok = yes create mask = 0775 directory mask = 0775
(In reply to comment #14) > Константин, попробуйте протестировать так > же, как монтировал Денис. > Опции user и uid разные. > Убедитесь что версии wine и linux-cifs у вас с > Денисом одинаковые. > Проблема у меня воспроизводилась и на > демо-базе. Размер в данном случае значения > не имеет. > Так же проверьте как себя ведет > смонтированный ресурс при использовании > опции noperm, потому что я замечал различия в > работе при явном указании владельца/группы > и noperm. > Да. Воспроизвелось. Монтировал: cifsmount //server/base8 /home/kipruss/base -o user=guest,file_mode=0660,dir_mode=0770,noperm и cifsmount //server/base8 /home/mastersin/base -o user=guest,file_mode=0660,dir_mode=0770,noperm user=guest - это нам надо из-за того, что шара с паролем. noperm на результат не влияет. Без него тоже воспроизводится. Насчёт доступа к cellar - он есть. Я сразу почему-то не догадался... Будем думать.
Итак, копирую письмо, в котором описал решение... Просьба внимательно просмотреть и проверить... Пишу, о том, что найдено решение проблемы запуска двух клиентов... Решение есть, но есть и где носом порыться... Приготовьтесь я немного опишу процесс, и всё, что мне не нравится, ибо не тривиально всё это, особенно для клиентов... Итак, запуск и установка вроде работают... Но первая непреодолимая преграда - это монтирование. Мы два дня голову ломали над тем, чтобы вместо $ cifsmount //server/base base -ouser=guest написать $ cifsmount //server/base base -ouser=guest,file_mode=0660,dir_mode=0770 Если смонтировать без этих опций 1С виснет даже на этапе запуска одного клиента, съедая при этом 99% процессора. Этот вопрос был описан, в частности, в #2599. К сожалению, никто так и не ответил, что такое может быть... А самое главное, как быть с этим делом клиентам? Это надо написать большими красными буквами на коробке, если больше нигде про это не написано... Вторая проблема - это сама база... Странное дело, но для тестирования хотелось бы иметь кучу разных баз, а у нас одна и то не вся работоспособная... В тестовой базе у нас забито два пользователя - Кассир и Администратор (Фёдоров). Так вот... Если зайти под Администратором, то всё вроде работает, но если зайти под Кассиром выходит сообщение о том, что склад не выбран и предлагается завершить работу... Далее, вне зависимости от ответа, появляется сообщение в стиле win3.11 "Запись дампа" с сообщением "Подождите, пожалуйста! Идёт сохранение информации об ошибке для возможности последующего анализа"... Это ведь надо догадаться, что это нормально и никто возможно не проверял... Но для нас это означало, что 1С вообще не работает, по крайней мере у нас... Начали уже грешить на релизы wine - может патчи шибко разные в наших сборках wine-1.0.9... Такая проблема есть не только с этой базой... Такая же проблема возникла и с базой по-меньше, которую с мигрировал kipruss@ в поисках тестовой базы, пока разбирались с запуском 1С на нормальной базе вообще (искали проблему, которая была в отсутсвии флагов file_mode=0660,dir_mode=0770)... Интересен тот факт, что в Windows и наша база с пользователем Кассир, и мигрированная база работают нормально. Если для кассира не выбрать завершение, то выдаётся окошко с документацией или чем-то похожим (детали можно уточнить у kipruss@)... Проблема третья - сама основная проблема #2599... Решена в рамках проверки запуска 1С etercifs, но включенными LinuxExtensions. Так вот, как я уже писал в #2563, поведение, которого мы добивались с помощью отключения LinuxExtensions легко можно добиться с помощью опции noperm - в этом случае авторизация полностью отдаётся на откуп серверу. В попытке проверить, а как же оно себя будет в этом случае вести, я и нашёл решение для текущей проблемы. Если включить LinuxExtensions (а лучше перезагрузить модуль не выключая), а потом смонтировать шару командой: $ cifsmount //server/base base -ouser=guest,noperm,file_mode=0660,dir_mode=0770 То всё работает. Кстати, user=guest - это тоже не обязательный параметр. Я его использую, чтобы шара была с паролем. Так что минимальный вариант выглядит так: $ cifsmount //server/base base -onoperm,file_mode=0660,dir_mode=0770 Если монтировать от рута, то нужно иметь в виду локальный маппинг пользователей и делать команду вида: $ mount //server/base base -ouid=$LOCAL_USER,gid=$LOCAL_GROUP,noperm,file_mode=0660,dir_mode=0770 В общем в альтах, а также там, где тоже есть cifsmount, как-то по удобнее.... Хотя я никак не могу понять как можно объяснить бухгалтеру выполение этой команды.... А также я никак не могу понять, как это сделать на автомате, не прибегая к костылям в fstab или pam_mount... Я думаю, что механизм должен подключать шару в момент доступа к ней... Иначе могут быть тормоза при перезагрузке сервера или проблемах в сетевом подключении... Резюме. Запустить удалось, но не все варианты оттестированы. Есть проблемы при работе самой 1С. Есть проблемы доступа к разным базам под разными пользователями.
> cifsmount //server/base8 /home/kipruss/base -o > user=guest,file_mode=0660,dir_mode=0770,noperm смысл использования file_mode, dir_mode и noperm одновременно? раньше noperm сбрасывал права на root:root(Х777). сейчас что-то поменялось?
(In reply to comment #19) > > cifsmount //server/base8 /home/kipruss/base -o > > user=guest,file_mode=0660,dir_mode=0770,noperm > смысл использования file_mode, dir_mode и noperm > одновременно? > раньше noperm сбрасывал права на root:root(Х777). > сейчас что-то поменялось? > Сперва тестировал без noperm. Потом просто добавил и не удалил остальное. P.S. Поскольку в etercifs убрано отключение LinuxExtersions, монтирование происходит с -o noperm всегда. В итоге будет достаточно команды: cifsmount //server/base /path/to/local/base в случае шары без пароля. А такую команду уже можно попытаться объяснить даже бухгалтеру. Но это пока предположение. Я пока не знаю замеченных Евгением проблем с разными пользователями.
(In reply to comment #19) > > cifsmount //server/base8 /home/kipruss/base -o > > user=guest,file_mode=0660,dir_mode=0770,noperm > смысл использования file_mode, dir_mode и noperm > одновременно? > раньше noperm сбрасывал права на root:root(Х777). > сейчас что-то поменялось? > Вы не внимательно прочли то, что я написал: "Так вот, как я уже писал в #2563, поведение, которого мы добивались с помощью отключения LinuxExtensions легко можно добиться с помощью опции noperm - в этом случае авторизация полностью отдаётся ___на_откуп_серверу___" Это означает, что в случае, если проставлен noperm проверка uid'ов и gid'ов, присылаемых сервером, на уровне драйвера отключена, и соответственно все проблемы прав доступа решаются при запросах на сервере... Вы полагаете, что file_mode, dir_mode отвечают за проверку прав доступа на уровне драйвера клиента? noperm сбрасывает права на root:root(Х777, X775, X755 и т.д.) только если монтировать это рутом... причём нужная маска как раз и выставляется с помощью дополнительных флагов... Если же монтировать, с помощью суидного cifsmount, то получаем: [sin@tartarus ~]$ cifsmount //server/base8 base8 -ouser=guest,file_mode=0660,dir_mode=0770 [sin@tartarus ~]$ mount|grep cifs //server/base8 on /home/sin/base8 type cifs (rw,mand,nosuid,nodev,user=sin) [sin@tartarus ~]$ ls -l ~/base8 итого 348944 -rwxrwxr-x 1 sin sin 356483072 Окт 15 20:57 1Cv8.1CD -rw-rw-r-- 1 sin sin 0 Окт 15 20:47 1Cv8.1CL drwxrwxr-x 2 sin sin 0 Окт 14 19:55 1Cv8FTxt drwxrwxr-x 2 sin sin 0 Окт 14 20:36 1Cv8Log -rwxrwxr-x 1 sin sin 162538 Авг 18 13:42 1Cv8.pfl -rwxrw-r-- 1 sin sin 323584 Окт 15 20:58 1Cv8tmp.1CD -rw-rw-r-- 1 sin sin 0 Окт 15 20:47 1Cv8tmp.1CL Если монтировать от рута то этого же эффекта можно добиться командой: $ mount //server/base base -ouid=$LOCAL_USER,gid=$LOCAL_GROUP,noperm,file_mode=0660,dir_mode=0770
(In reply to comment #20) > (In reply to comment #19) > > > cifsmount //server/base8 /home/kipruss/base -o > > > user=guest,file_mode=0660,dir_mode=0770,noperm > > смысл использования file_mode, dir_mode и noperm > > одновременно? > > раньше noperm сбрасывал права на root:root(Х777). > > сейчас что-то поменялось? > > > > Сперва тестировал без noperm. Потом просто > добавил и не удалил остальное. > > P.S. Поскольку в etercifs убрано отключение etercifs - это светлое будущее, к кторому нужно ещё подготовиться... Во-первых, решив проблему проверки наличия нашего драйвера; во-вторых, изменив wine на использование новых значений флагов и проставив правильные на то зависимости; во-третьих, исправив кучу проблем, в частности oplocks... Так что сейчас, предлагаю оторвать LinuxExtensions в linux-cifs и составить подробную документацию по монтированию... Возможно стоит сделать скрипты и подумать о процессе автомазации монтирования с помоьщью того же automount. > LinuxExtersions, монтирование происходит с -o noperm > всегда. В итоге будет достаточно команды: > > cifsmount //server/base /path/to/local/base > > в случае шары без пароля. А такую команду > уже можно попытаться объяснить даже > бухгалтеру. > Чушь... На надо такое предлагать конечным пользователям... Только по желанию, но вы пока альтернатив не предложили.. Руками каждый раз - это не дело... В крайнем случае описание для внедренцев, которые сделают костыли в pam_mount для таких не завершённых решений... > Но это пока предположение. Я пока не знаю > замеченных Евгением проблем с разными > пользователями. > Каких проблем с разными пользователями? Ты о чём? Чего ты не знаешь?
(In reply to comment #22) > Каких проблем с разными пользователями? Ты > о чём? Чего ты не знаешь? > Вот об этом я хотел спросить поподробнее: (In reply to comment #18) > Есть проблемы > доступа к разным базам под > разными пользователями. > Если, конечно, ты не имел в виду "Кассира" и "Админа". Об этом я сто-то не подумал тогда.
> (In reply to comment #18) > > > Есть проблемы > > доступа к разным базам под > > разными пользователями. > > > > Если, конечно, ты не имел в виду "Кассира" и > "Админа". Об этом я сто-то не подумал тогда. > Именно это и имел в виду...
Created attachment 792 [details] Таблица тестирования запуска и совместной работы 1cv8.1 Протестировал запускаемость 1с на некотором тестовом покрытии. Перебирал разные параметры: клиент, сервер, наличие/отсутствие некоторых параметров монтирования, состояние LinuxExtensions Таблица - в приложении pdf Выводы: 1. На виндовой шаре флаг LinuxExtensions не имеет смысла. Ни разу не удалось запустить программу 2. При отключенном LinuxExtensions на самбе 1с совместно работает только в случае L → W 3. При отключенном LinuxExtensions, если нет параметра file_mode, то программа виснет
(In reply to comment #25) > 1. На виндовой шаре флаг LinuxExtensions не имеет > смысла. Ни разу не удалось запустить > программу Это понятно, потому что сервер не поддерживает их (они на самом деле Unix Extensions, просто в CIFS их назвали немного по-левому). А положительные выводы есть?
(In reply to comment #26) > > А положительные выводы есть? > Положительный вывод - то, что хоть как-то, пока только на самбе, но совместная работа возможна. Кроме описанных Женей в http://bugs.etersoft.ru/show_bug.cgi?id=2599#c18 других положительных выводов пока нет. Если в Питере все же удавалось запускать 1сv8.1 на виндовой шаре, то хотелось бы узнать об этом поподробнее.
(In reply to comment #8) > Весь файл вывода out1: > Ещё раз обращаю внимание на проблему: попробую описать словами ту часть кода, где возникают непонятные вещи: Вот мы открываем файл, получаем дескриптор > open("/home/kipruss/.wine/dosdevices/e:/home/kipruss/base", > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 97 > fstat64(97, {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 > fcntl64(97, F_SETFD, FD_CLOEXEC) = 0 > getdents64(97, /* 9 entries */, 16384) = 272 > close(97) = 0 ... закрываем файловый дескриптор (в данном случае - 97). (тут убрал часть кода, в которой нет упоминания о файловом дескрипторе 97) Далее почему-то происходит попытка работы с уже закрытым файловым дескриптором и почему-то это не появляется соответствующая ошибка. > msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, > {97}}, msg_flags=0}, 0) = 4 > fcntl64(97, F_SETFD, FD_CLOEXEC) = 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > fstat64(97, {st_mode=S_IFREG|S_ISGID|0767, st_size=162538, ...}) = 0 > rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > _llseek(97, 162538, [162538], SEEK_SET) = 0 > gettimeofday({1224058659, 556558}, NULL) = 0 > time(NULL) = 1224058659 > time(NULL) = 1224058659 > rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 > write(3, > "'\0\0\0\0\0\0\0\0\0\0\0\200\4\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0"..., 64) = > 64 > read(5, > "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = > 64 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > gettimeofday({1224058659, 556962}, NULL) = 0 > time(NULL) = 1224058659 > rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > _llseek(97, 0, [0], SEEK_SET) = 0 > rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily > unavailable) > poll([{fd=97, events=POLLIN}], 1, -1) = 1 ([{fd=97, revents=POLLIN}]) > read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily > unavailable) > Существует предположение, что поскольку для старых ядер такого не было, то, видимо, в новом cifs появилась такая проблема.
(In reply to comment #28) > (In reply to comment #8) > > Весь файл вывода out1: > > > > Ещё раз обращаю внимание на проблему: > > попробую описать словами ту часть кода, где > возникают непонятные вещи: > > Вот мы открываем файл, получаем дескриптор > > > open("/home/kipruss/.wine/dosdevices/e:/home/kipruss/base", > > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 97 Но это же не файл. > Далее почему-то происходит попытка работы > с уже закрытым файловым дескриптором и > почему-то это не появляется > соответствующая ошибка. > > > msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, > > {97}}, msg_flags=0}, 0) = 4 > > fcntl64(97, F_SETFD, FD_CLOEXEC) = 0 > > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > > fstat64(97, {st_mode=S_IFREG|S_ISGID|0767, st_size=162538, ...}) = 0 > > rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 > > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > > _llseek(97, 162538, [162538], SEEK_SET) = 0 Похоже, всё же пропустили, как он открылся. ... > > read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily > > unavailable) > > poll([{fd=97, events=POLLIN}], 1, -1) = 1 ([{fd=97, revents=POLLIN}]) > > read(97, 0x33e50c, 16) = -1 EAGAIN (Resource temporarily > > unavailable) > > > > Существует предположение, что поскольку > для старых ядер такого не было, то, видимо, в > новом cifs появилась такая проблема. Возможно изменился режим блокирование, для этих файлов блокировка стала обязательной? Легко же посмотреть, в каком случае модуль CIFS может вернуть EAGAIN из вызова read.
Created attachment 813 [details] Обновленая таблица тестирования запуска и совместной работы 1cv8.1 Добавлено: L → W → L : Означает, что проверены все варианты: L → W, W → L, L → L
Перевешиваю для тестирования. Тут слишком много написали, пора закрывать.
Проверил на последних сборках. Кажется от проблем в CIFS с 1Cv81 избавились наконец то. Проверил L>W, W>L, L>L. Удалось зайти во всех случаях. wine-etersoft-sql-1.0.9-alt0.M41.13 libwine-1.0.9-alt0.M41.34.1 wine-1.0.9-alt0.M41.34.1 libwine-gl-1.0.9-alt0.M41.34.1 etercifs-3.8.0-alt0.M41.4
