Created attachment 1124 [details] Частичная реализация WNetGetUniversalNameA В wine-etersoft-devel/mpr я закоммитил тест universal_name, с помощью которого можно посмотреть, как работает WNetGetUniversalName. Я отправил в рассылку примерную реализацию WNetGetUniversalNameA через WNetGetConnectionA (также приложено к баге). Что нужно сделать: 1. Реализовать WNetGetUniversalNameA как обёртку вокруг WNetGetUniversalNameW. Смотрим уже готовый патч http://www.winehq.org/pipermail/wine-patches/2007-May/039568.html улучшаем. Может что-то ещё есть. 2. Реализовать WNetGetUniversalNameW через WNetGetConnectionA по накатанной в моём патче схеме. 3. Реализовать тесты в dlls/mpr/test на ситуации, проверяемые в wine-etersoft-devel/mpr/run.sh Важные замечания: 1. В Wine подсоединённым диском считается диск, оформленный как $ ls -l s: s: -> unc/server/share то есть ссылающийся относительной ссылкой на каталог unc. 2. В Windows для ресурса \\server\tmp, подключенного как диск T:, получаем: Calling WNetGetUniversalName with Local Path = T:\lav WNetGetUniversalName returned success for InfoLevel=UNIVERSAL_NAME_INFO_LEVEL Universal name = \\Server\tmp\lav WNetGetUniversalName returned success for InfoLevel=REMOTE_NAME_INFO_LEVEL Universal name = \\Server\tmp\lav Connection name = \\Server\tmp Remaining path = \lav Деление на Universal/Connection/Remaining я пока не реализовал. 3. Возможно исправления этой функции отсутствуют неспроста, надо посмотреть в рассылке.
Версия wine: WINE@Etersoft 1.0 Local 1.0.10 centos 5.3 eter23-16 При запуске Консультанта появляется ошибка: "no network" fixme:mpr:WNetGetUniversalNameA ("F:", 0x00000002, 0x33f1ec, 0x33f1e8): stub Можно ли простимулировать решение этой ошибки?
(In reply to comment #1) > Версия wine: > WINE@Etersoft 1.0 Local 1.0.10 centos 5.3 eter23-16 > При запуске Консультанта появляется > ошибка: > "no network" Уважаемый Антон! Комизм ситуации в том, что вы пишете: "В версии Local появляется ошибка 'no network', можно ли это исправить?" :) > fixme:mpr:WNetGetUniversalNameA ("F:", 0x00000002, 0x33f1ec, 0x33f1e8): stub > > Можно ли простимулировать решение этой > ошибки? Что представляет из себя диск F: - на что ссылается? Должен быть путь вида unc/server/share
Уточняю)) Диск F: это: f: -> /mnt/Consultant/ Что показывает mount: //192.168.170.4/Consultant on /mnt/Consultant type cifs (rw,mand) rpm -q etercifs etercifs-4.3.6-eter1centos env WINEPREFIX="/home/user/.wine" WINEDLLOVERRIDES="ole32,oleaut32,olepro,rpcrt4=n" wine "F:\Cons.exe" В консоли: fixme:mpr:WNetGetUniversalNameA ("F:", 0x00000002, 0x33f1ec, 0x33f1e8): stub В Консультанте появляется окошко с ошибкой: [WNetGetUniversalName - F:] :NOT_CONNECTED
На эту тему есть патч в рассылке: From: Maarten Lankhorst <m.b.lankhorst@gmail.com> Date: Tue, 22 May 2007 21:59:28 +0200 Subject: [PATCH] mpr: Implement WNetGetUniversalNameW using WNetGetConnectionW Патч не принят, и нет его обсуждения. Знакомая ситуация :)
(In reply to comment #3) > Уточняю)) > > Диск F: это: > > f: -> /mnt/Consultant/ как я написал, должен быть f: -> unc/cons/share unc/cons/share -> /mnt/Consultant > Что показывает mount: > //192.168.170.4/Consultant on /mnt/Consultant type cifs (rw,mand) > > rpm -q etercifs > etercifs-4.3.6-eter1centos > > env WINEPREFIX="/home/user/.wine" > WINEDLLOVERRIDES="ole32,oleaut32,olepro,rpcrt4=n" wine "F:\Cons.exe" А зачем OLE в native?
Native нужен для вот этого: В Консультанте не работает вызов офиса (Word/Writer) http://bugs.etersoft.ru/show_bug.cgi?id=3924 Патч включать будете?
Хотя проверю в понедельник еще раз.. на это не обращал внимания..
Скажите, когда включите патч..
(In reply to comment #8) > Скажите, когда включите патч.. Пока никакой патч включать не собираемся. Вы хотели проверить схему u: -> unc/server/share unc/server/share -> смонтированный Консультант + диск U: сделать сетевым в winecfg.
env WINEPREFIX="/home/PatsevAA/.wine" WINEDLLOVERRIDES="ole32,oleaut32,olepro,rpcrt4=n" wine "U://cons.exe" fixme:mpr:WNetGetUniversalNameA ("U:", 0x00000002, 0x33e6b4, 0x33e6b0): stub fixme:mpr:WNetGetUniversalNameA ("U:", 0x00000002, 0x33df1c, 0x33df18): stub fixme:mpr:WNetGetUniversalNameA ("U:", 0x00000002, 0x33ef5c, 0x33ef58): stub fixme:mpr:WNetGetUniversalNameA ("U:", 0x00000002, 0x33ef5c, 0x33ef58): stub fixme:mpr:WNetGetUniversalNameA ("U:", 0x00000002, 0x33ef5c, 0x33ef58): stub Ошибка: [WNetGetUniversalNameA U:] MORE_DATA
(In reply to comment #8) > Скажите, когда включите патч.. > Патч включать не будем. Он не совсем корректно написан, к тому же проблему он не решит.
Частично реализовал WNetGetUniversalNameA (через WNetGetUniversalNameW) Немного поторопился. Сначала нужно было доработать WNetGetUniversalNameW и создать тесты для неё, а потом уже браться за WNetGetUniversalNameA.
Скажите, когда протестировать надо будет...
написал тест. Заметил некоторые особенности работы в win2k3 (под winXP пока нет возможности проверить): 1) в lpBufferSize не возвращается количество записанных байт. Там просто остаётся старое значение. 2) Функция поддерживает определение необходимого размера буфера, но как-то странно. Указатель lpBuffer не должен быть нулевым, иначе функция сообщает об ошибке (WN_BAD_VALUE), и так и не записывает необходимый размер буфера. 3) LastError не должно устанавливаться, если возвращается WN_NO_ERROR
Сделал 2 маленьких патча. Первый не выставляет LastError, если нет ошибки. Второй добавляет проверку входного параметра lpBuffer.
добавил тесты для mpr.dll. Послал патч в официальную ветку
Для начала решил сделать хак, исправляющий проблему, а потом, если будет время, делать нормальный патч. Попытался найти хоть одну бутылку с консультантом, где можно бы было воспроизвести багу - так и не нашёл
(In reply to comment #17) > Для начала решил сделать хак, исправляющий > проблему, а потом, если будет время, делать > нормальный патч. > > Попытался найти хоть одну бутылку с > консультантом, где можно бы было > воспроизвести багу - так и не нашёл > Я проверю... скажите только какую версию надо проверять?
> > Я проверю... скажите только какую версию > надо проверять? > К сожалению так не получится. "В слепую" патчи лучше не делать. И выкладывать надо только проверенные изменения. Так что буду ждать бутылку, в которой бага воспроизводится. Про бутылку есть бага #4024. Возможно вы как-то сможете поспособствовать её решению. У саппорта воспроизвести не получается.
Просьба больше сюда ничего не писать и не обсуждать Консультант. Это бага про реализацию функции WNetGetUniversalName*.
Сколько надо денег вам положить чтобы была исправлена эта ошибка? До сих пор появляется ошибка: [WNetGetUniversalName - F:] :NOT_CONNECTED
(In reply to comment #21) > Сколько надо денег вам положить чтобы была > исправлена эта ошибка? > > До сих пор появляется ошибка: > > [WNetGetUniversalName - F:] :NOT_CONNECTED Антон, Вы же написали здесь http://bugs.etersoft.ru/show_bug.cgi?id=4379 что всё работает. Если проблема всё ещё имеется, давайте обсудив в баге 4379, сюда писать не нужно. Я предполагаю, что у Вас не выбран диск F: сетевым (через winecfg).
По данной проблеме не планируется ничего делать в ближайшее время
исправил WNetGetUniversalNameA. теперь минимум преобразований, они осуществляются WNetGetConnectionA. убрал лишние переменные. добавлены проверки. отправил патч на wine-patches@
добавил проверки на возвращаемые значения для функции WNetGetConnectionA. добавил проверки на соответствие длины строки и размера предоставленного буфера. отправил патч на wine-patches@
добавил в тест проверки различных вариантов вызова функции. дополнил функцию дополнительными проверками, в частности if (!*lpBufferSize)
переделал тест. теперь запускается под windows без ошибок. переделал тест для eterwine. отправил патч на winehq
тест проверки прошел. замечаний нет, но не принят.
err:mpr:get_drive_connection failed to open mount manager err 2 mpr.c:99: Test failed: WNetGetUniversalNameA failed: 000008ca
переделал тест для eterhack. переделал WNetGetUniversalNameA, теперь она работает как оболочка вокруг WNetGetUniversalNameW. отправил патчи на wine-patches@
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.