Bug 1959

Произвёл те же самы манипуляции на сервере (подключал /var/local/sharebase)
Смотреть скриншоты.

Created attachment 767 [details]
#1

Смотреть имя пути к /dosdevice

Created attachment 768 [details]
#2

И пути далее переходя в /unc

Чем может быть вызвана данная проблема?

Такая же проблема и на cellar
Бутылка 1c7727-night

В общем, багу воспроизвёл.
Бутылка 1c7727-night
"Информационная База #1"

Created attachment 783 [details]
Скрин проблемы с открытием таблицы

Та же проблема проиллюстрирована в
http://rt.etersoft.ru:80/Ticket/Display.html?id=9303

баг ориентировочно происходит при установки текущей директории функцией SetCurrentDirectoryW

trace:file:RtlSetCurrentDirectory_U curdir now L"C:\\Program Files\\1Cv77\\BIN\\" 0xfc
trace:file:RtlGetCurrentDirectory_U (520 0x32f7a8)
trace:file:RtlDosPathNameToNtPathName_U (L"\\\\someserver\\share\\TIS2\\DemoDB\\",0x32f928,(nil),(nil))
trace:file:RtlGetFullPathName_U (L"\\\\someserver\\share\\TIS2\\DemoDB\\" 520 0x32f61c (nil))
trace:file:wine_nt_to_unix_file_name L"\\??\\UNC\\someserver\\share\\TIS2\\DemoDB\\" -> "/net/wine/bottles/1c77/.wine-1c7727-night/dosdevices/unc/someserver/share/TIS2/DemoDB/"
trace:file:RtlSetCurrentDirectory_U curdir now L"UNC\\someserver\\share\\TIS2\\DemoDB\\" 0xc8
trace:file:RtlDosPathNameToNtPathName_U (L"UNC\\someserver\\share\\TIS2\\DemoDB\\UNC\\someserver\\share\\TIS2\\DemoDB\\Usr1\\",0x32f928,(nil),(nil))

RtlDosPathNameToNtPathName_U -> dos_path == L"UNC\\someserver\\share\\TIS2\\DemoDB\\UNC\\someserver\\share\\TIS2\\DemoDB\\Usr1\\" detected!!!
             <----------------------

trace:file:RtlGetFullPathName_U (L"UNC\\someserver\\share\\TIS2\\DemoDB\\UNC\\someserver\\share\\TIS2\\DemoDB\\Usr1\\" 520 0x32f61c (nil))
warn:file:wine_nt_to_unix_file_name L"UNC\\someserver\\share\\TIS2\\DemoDB\\UNC\\someserver\\share\\TIS2\\DemoDB\\Usr1\\" not found in /net/wine/bottles/1c77/.wine-1c7727-night/dosdevices/unc/someserver/share/TIS2/DemoDB

(In reply to comment #9)
> баг ориентировочно происходит при
> установки текущей директории функцией
> SetCurrentDirectoryW

однако, если упасть в месте первого проявления в логе неправильного пути, то видно, что неправельный путь попадает откуда-то сверху еще в SetCurrentDirectoryA

=>0 0x7bc59ed5 RtlDosPathNameToNtPathName_U+0xfc(dos_path=0x7ffd8c00, ntpath=0x32f928, file_part=(nil), cd=(nil)) [/srv/mibori/Projects/wine/dlls/ntdll/path.c:366] in ntdll (0x0032f8dc)
  1 0x7bc5b4b5 RtlSetCurrentDirectory_U+0x71(dir=0x32f97c) [/srv/mibori/Projects/wine/dlls/ntdll/path.c:983] in ntdll (0x0032f95c)
  2 0x7b87ec6a SetCurrentDirectoryW+0x32(dir=0x7ffd8c00) [/home/mibori/Projects/wine/dlls/kernel32/path.c:1417] in kernel32 (0x0032f98c)
  3 0x7b87eceb SetCurrentDirectoryA+0x42(dir="UNC\someserver\share\TIS2\DemoDB\UNC\someserver\share\TIS2\DemoDB\Usr1\") [/home/mibori/Projects/wine/dlls/kernel32/path.c:1435] in kernel32 (0x0032f9bc)
  4 0x2200f525 in seven (+0xf525) (0x00000078)
  5 0x00000000 (0x00000000)

строчка чуть выше присходит с правильным путём

trace:file:RtlSetCurrentDirectory_U curdir now L"UNC\\someserver\\share\\TIS2\\DemoDB\\" 0xc8


падение в ней даёт такой бэктрейс:

=>0 0x7bc5b758 RtlSetCurrentDirectory_U+0x35a(dir=0x32f96c) [/srv/mibori/Projects/wine/dlls/ntdll/path.c:1036] in ntdll (0x0032f94c)
  1 0x7b87ec6a SetCurrentDirectoryW+0x32(dir=0x7ffd8c00) [/srv/mibori/Projects/wine/dlls/kernel32/path.c:1417] in kernel32 (0x0032f97c)
  2 0x7b87ed5a SetCurrentDirectoryA+0xb1(dir="\\someserver\share\TIS2\DemoDB\") [/srv/mibori/Projects/wine/dlls/kernel32/path.c:1445] in kernel32 (0x0032f9bc)
  3 0x2200f4c6 in seven (+0xf4c6) (0x00000078)
  4 0x00000000 (0x00000000)

как видно что-то происходит между двумя вызовами

trace:file:RtlSetCurrentDirectory_U curdir now
L"UNC\\someserver\\share\\TIS2\\DemoDB\\" 0xc8

и

trace:file:RtlDosPathNameToNtPathName_U
(L"UNC\\someserver\\share\\TIS2\\DemoDB\\UNC\\someserver\\share\\TIS2\\DemoDB\\Usr1\\",0x32f928,(nil),(nil))

по бэктрейсам видно, что два этих вызова порождаются двумя разными вызовами SetCurrentDirectoryA

в первом случае dir="\\someserver\share\TIS2\DemoDB\"
во втором случае dir="UNC\someserver\share\TIS2\DemoDB\UNC\someserver\share\TIS2\DemoDB\Usr1\"

соответственно.

попробую посмотреть, что в других каналах.

(In reply to comment #12)

наблюдая за relay обнаружил несколько аномальное поведение GetFullPathNameA
первым аргументом которого должно быть имя файла.

Кроме того, что вместо имени файла там папка со слешем на конце, так там имя папки с относительным путём UNC\\someserver\\share\\TIS2\\DemoDB\\

завтра попробую написать тест на это функцию.

попытки как-то изменить функции под правильный результат (чтобы запуск проходил), не увенчались успехом.

между тем стоить отметить, что префикс UNC не должен никак фигурировать в WinAPI и нужно искать его проникновение туда. Очень вероятно, что ошибка происходит именно из-за этого, а не из-за удвоения путей.

попробую снова проанализировать логи на предмет этого.

(In reply to comment #14)
> попробую снова проанализировать логи на
> предмет этого.

последовательно подставляя в трейсы возвращаемые значения функций обнаружил следующую странность

RtlDosPathNameToNtPathName_U (L"\\\\someserver\\share\\TIS2\\DemoDB\\usrdef\\users.usr",0x32f28c,(nil),(nil))
    RtlGetFullPathName_U (L"\\\\someserver\\share\\TIS2\\DemoDB\\usrdef\\users.usr" 520 0x32efb8 (nil))
RtlDosPathNameToNtPathName_U  -> ntpath=L"\\??\\UNC\\someserver\\share\\TIS2\\DemoDB\\usrdef\\users.usr" cd=<null>

RtlDosPathNameToNtPathName_U на выходе даёт путь с "UNC".
Если отталкиваться от того, что в WinAPI не должно проникать "UNC", то данное возвращаемое значение не верно. Это с одной стороны.

С другой стороны, что тогда должна возвращать эта функция?

> RtlDosPathNameToNtPathName_U
> (L"\\\\someserver\\share\\TIS2\\DemoDB\\usrdef\\users.usr",0x32f28c,(nil),(nil))
>     RtlGetFullPathName_U

> RtlDosPathNameToNtPathName_U  ->
> ntpath=L"\\??\\UNC\\someserver\\share\\TIS2\\DemoDB\\usrdef\\users.usr"
> cd=<null>

из ходя из http://en.wikipedia.org/wiki/Path_(computing)#Uniform_Naming_Convention
логика RtlDosPathNameToNtPathName_U верна.

\\?\UNC\ComputerName\SharedFolder\Resource -- это "длинный UNC"

странностью остаются что не \\?\UNC\ComputerName возвращается, а \??\UNC\ComputerName

что на первый взгляд ни одно и тоже.

при этом явно прописано в константах:

static const WCHAR NTDosPrefixW[] = {'\\','?','?','\\',0};
static const WCHAR UncPfxW[] = {'U','N','C','\\',0};

> 
> странностью остаются что не \\?\UNC\ComputerName
> возвращается, а \??\UNC\ComputerName
> 

если поменять NTDosPrefixW[] = {'\\','?','?','\\',0}; на {'\\','\\','?','\\',0};
то ничего не запускается вобще.

Патч 

http://lists.etersoft.ru/pipermail/wine-patches/2009-February/000282.html

решает проблему.


Функция RtlSetCurrentDirectory_U, когда путь был c 'UNC', ошибочно его обрабатывала (делала вместо него не абсолютный, а относительный). 

Кроме того, ее логика на счет длинных UNC путей не верна.

Если путь UNC, то возвращаемый результат не должен быть длинным UNC (с вопросиками). А должен быть обычным \\server\shared\folder

1.0.10 eter20/14