View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000190 | Known Error | Command Line/Execute | public | 2006-05-25 04:12 | 2009-10-23 15:22 |
Reporter | Zuz | Assigned To | |||
Priority | normal | Severity | crash | Reproducibility | always |
Status | closed | Resolution | not fixable | ||
Summary | 0000190: Некорректная работа после \\?\UNC\<hostname>\<sharename>\<dirname> , а также cd \\.\<disk>:\<dir>, cd \\?\<disk>:\<dir> и пр. | ||||
Description | 1. Схлопывание FAR после ряда команд (лог от FExcept не создаётся, повторяется в 1.80 alpha 1 (build 98)). Запускаем в командной строке FAR'a: cd \\?\UNC\<hostname>\<sharename>\<dirname> где <hostname> - это IP-адрес или имя хоста на котором существует шара с именем <sharename> и директория <dirname> (имя шары и директории не принципиально) Затем запускаем в командной строке FAR'a: cd \\..\..\ FAR молча закрывается. 2. Лишние "две точки" (кстати в 1.80 alpha 1 (build 98) этого нет) Запускаем в командной строке FAR'a: cd \\?\UNC\<hostname>\<sharename>\<dirname> Переходим по ".." на уровень выше, видим, что в корне диска есть лишние ".." 3. Проблемы с навигацией на уровень выше (повторяется в 1.80 alpha 1 (build 98)) Запускаем в командной строке FAR'a: cd \\.\<disk>:\<dir> или cd \\?\<disk>:\<dir> после команды не работает навигация как по ".." так и команды типа cd .. По идее первый вариант вообще не должен открывать каталог. P.S. В этом направлении много можно чего накопать. Записал так, чтобы не забыли. | ||||
Tags | No tags attached. | ||||
|
в 1 пункт очепятка вкралась, падает после cd \..\..\, а не cd \\..\..\. |
|
А... можно пока по 1.80 не публиковать баги? ОНО даже еще и не альфа. |
|
Оно дано для сравнения (а не как баг 1.80), что какая-то часть кода там корректно обрабатывает данную ситуацию и возможно проще посмотреть, как там сие решено. |
|
Валится где-то внутри... на GetFileAttributes("\..\..\") Получается, что винды не переваривают такю конструкцию. Че делать бум? |
|
по поводу п.2 - две точки будут отсутствовать в корне только на диске, имеющим букву, в остальных случаях - будут. |
|
А с какой целью и кем оно вызывается? И нельзя ли сначала преобразовать путь с помощью GetFullPathName или чего там ещё? P.S. Если это баг Windows, то если не сложно, то можно миниконцепт на котором повторяется, я его M$ передам... |
|
GetFullPathName тоже заваливает ФАР при таких же условиях. Т.е. если у нас на панели: \\?\UNC\<hostname>\<sharename>\<dirname> то АПИ функции на "\..\..\" валятся. без "\\?\UNC\" и "\\.\<disk>:" эта конструкция ("\..\..\") замечательно проскакивает. А вызываю GetFileAttributes() для того, что бы проверить че хотел юзер и нужно ли туда вваливать (куда он пожелал). |
|
Вообще-то для \\?\ и \\.\ незя вообще использовать относительные пути. Так написано в MSDN. |
|
Тогда что? Хмм... тогда нужна функция-конструктор пути. И хто нарисует? |
|
2 alexy: А можно ссылочку в MSDN про замечание об относительных путях (а то как-то я это упустил)? 2 vskirdin: по п.2, а что существует проблема определения, что какой-то конкретный каталог это корень диска? |
|
Универсальная функция нужна... Напишешь? |
|
2 zuz: Maximum Path Length In the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters. A path is structured in the following order: drive letter, colon, backslash, components separated by backslashes, and a null-terminating character, for example, the maximum path on the D drive is D:\<256 chars>NUL. The Unicode versions of several functions permit a maximum path length of approximately 32,000 characters composed of components up to 255 characters in length. To specify that kind of path, use the "\\?\" prefix. Note The maximum path of 32,000 characters is approximate, because the "\\?\" prefix can be expanded to a longer string, and the expansion applies to the total length. For example, "\\?\D:\<path>". To specify such a UNC path, use the "\\?\UNC\" prefix. For example, "\\?\UNC\<server>\<share>". These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification. An implication of this is that you cannot use forward slashes to represent path separators, or a period to represent the current directory. You cannot use the "\\?\" prefix with a relative path. Relative paths are limited to MAX_PATH characters. When using the API to create a directory, the specified path cannot be so long that you could not append an 8.3 file name. The shell and the file system may have different requirements. It is possible to create a path with the API that the shell UI cannot handle. Relative Paths For functions that manipulate files, the file names may be relative to the current directory. A file name is relative to the current directory if it does not begin with a disk designator or directory name separator, such as a backslash (\). If the file name begins with a disk designator, it is a full path. |
|
Дополнение к п.3, при работе с префиксом типа "\\?\Volume{GUID}\" те же проблемы. 2 vskirdin: ТЗ на необходимые функции можно увидеть? |
|
так, п.3 исправил |
|
Кстати, а куда мы хотели попасть, задавая "\..\..\" (в п.1) Что ожидаем? |
|
По идее это не корректный путь, т.к. ведущий слеш указывает на корневую директорию относительно текущей директории процесса в контексте которого вызывается функция. Пример: пусть мы в c:\1\2\3\4 (причем это текущая директория процесса) тогда cd \1\2 переместит нас в c:\1\2 И по логике команды cd \..\..\ мы хотим на два уровня выше корня, что ни есть правильно, но падать не должно. |
|
если к примеру, мы находимся в c:\dir\ cd ..\..\ — должно вывести нас в c:\ пусть cd \..\..\ будет выводить туда-же, разве не логично? |
|
Думаю, что не логично, должно ругаться на некоррентный путь, но сейчас если просто дать такую команду, то так и происходит (как для обынчых локальных путей так и для UNC). Поэтому можно и так и так, главное, чтоб не падало ;-) |
|
2Kildor нифига не логично. |
|
а чем \..\..\ отличается от \folder\..\..\ ? |
|
Это тоже некорректный путь в контексте заявленной проблемы. А отличается тем, что FAR не валит (точнее кусочек Windows) в отличие от cd \..\..\ и тому подобных команд. Кардинальный способ решения проблемы, это исключить поддержку относительных путей для нотации \\?\ и ругаться, что сие мол не поддерживается, а в справке ссылаться на MSDN: "Also, you cannot use the "\\?\" prefix with a relative path. Relative paths are limited to MAX_PATH characters". А для нотации \\.\ вообще запретить навигацию и открывать соответствующий путь как образ диска, например, как это 7-Zip делает для CD/DVD в виде файла ISO образа. Если вдумчиво прочитать: "Relative Paths For functions that manipulate files, the file names can be relative to the current directory. A file name is relative to the current directory if it does not begin with one of the following: • A disk designator, which is either a drive letter followed by a colon, or a server name and share name (\\servername\sharename). • A directory name separator, such as a backslash, for example, \subdir). If the file name begins with a disk designator and a backslash (\), it is a full path (for example, c:\tmp). If a file name begins with only a disk designator, it is a relative path to the current directory on the drive with the specified letter (for example, c:tmp.txt refers to a file in the current directory on the C drive)". То видно противоречие, что в первом блоке написано, что путь не относительный для текущей директории процесса, если он начинается с обратного слеша (\subdir), с другой стороны написано, что полное имя файла обязательно начинается с описателя диска и идущего за ним обратного слеша. Забавно, что путь типа с:test.txt тоже является относительным для текущей директории (не совсем очевидный факт, но многим известный). Т.е. по идее путь типа \..\..\ или даже \test не являются относительными для текущей директории процесса, но и не являются полными. По опыту они являются относительными для описателя диска текущей директории процесса. ------------------------------------------------------------------------------- Дополнение бага пункт 4: Команды типа cd \test не отрабатывают для нотаций (\\?\, \\?\UNC\, \\.\), но работают, для обычных UNC путей и полных путей. Выдается ошибка: "Не найден сетевой путь". А для вполне корректного пути команда cd \test\..\ (которая работает с UNC путями и обычными полными путями) отказывается работать с сообщением: "Синтаксическая ошибка в имени файла, имени папки или метке тома". Осталось решить относительные это пути или нет и должны ли в таком случае работать команды cd. ------------------------------------------------------------------------------- P.S. быстрая сцилка на MSDN для удобства http://msdn.microsoft.com/library/en-us/fileio/fs/naming_a_file.asp |
|
Как я понимаю - осталось исправить падение в п.1. чтоб закрыть этот баг? |
|
Ало? |
|
Баг винды. Ничего не можем поделать. Переношу в KnownErrors. |
|
Zuz, какой статус у этой фигни сейчас? |
|
Видимо нужно обсудить, то что я изложил здесь http://bugs.farmanager.com/view.php?id=190#c257 А по-хорошему я прогоню как нибудь с DebugTools всё это, чтоб понять в чём проблема. |
|
test |
|
Куку? Что с этим в текущей версии? |
|
Что с этим багом в наше время в 2.0? |
|
На первый взгляд всё работает. |
Date Modified | Username | Field | Change |
---|---|---|---|
2006-05-25 04:12 | Zuz | New Issue | |
2006-05-25 21:16 | Zuz | Note Added: 0000189 | |
2006-05-29 01:20 | vskirdin | Note Added: 0000191 | |
2006-05-29 02:28 | Zuz | Note Added: 0000193 | |
2006-07-03 05:10 | vskirdin | Note Added: 0000222 | |
2006-07-03 05:35 | vskirdin | Note Added: 0000223 | |
2006-07-03 05:41 | Zuz | Note Added: 0000225 | |
2006-07-03 06:00 | vskirdin | Note Added: 0000226 | |
2006-07-03 07:33 | alexy | Note Added: 0000227 | |
2006-07-03 07:51 | vskirdin | Note Added: 0000228 | |
2006-07-03 20:31 | Zuz | Note Added: 0000230 | |
2006-07-03 23:56 | vskirdin | Note Added: 0000231 | |
2006-07-04 04:24 | alexy | Note Added: 0000232 | |
2006-07-04 23:28 | Zuz | Note Added: 0000233 | |
2006-07-24 12:01 | vskirdin | Status | new => assigned |
2006-07-24 12:01 | vskirdin | Assigned To | => vskirdin |
2006-07-24 12:36 | vskirdin | Note Added: 0000247 | |
2006-07-24 12:37 | vskirdin | Note Added: 0000248 | |
2006-07-25 02:30 | Zuz | Note Added: 0000250 | |
2006-07-25 02:31 | Zuz | Note Edited: 0000250 | |
2006-07-25 22:02 | Kildor | Note Added: 0000253 | |
2006-07-25 22:53 | Zuz | Note Added: 0000254 | |
2006-07-25 23:41 | alexy | Note Added: 0000255 | |
2006-07-26 02:15 | Kildor | Note Added: 0000256 | |
2006-07-26 05:06 | Zuz | Note Added: 0000257 | |
2006-08-29 00:04 | vskirdin | Category | _Common => Command Line/Execute |
2006-08-29 00:04 | vskirdin | Assigned To | vskirdin => |
2006-09-23 19:13 | alexy | Note Added: 0000287 | |
2007-02-04 12:19 | alexy | Note Added: 0000400 | |
2007-02-06 08:56 | alexy | Note Added: 0000407 | |
2007-02-06 08:56 | alexy | Status | assigned => acknowledged |
2007-02-06 08:56 | alexy | Resolution | open => not fixable |
2007-02-06 08:56 | alexy | Project | Far Manager 1.7x => Known Error |
2007-07-16 12:12 | alexy | Status | acknowledged => new |
2007-08-13 19:47 | Zuz | Relationship added | has duplicate 0000313 |
2008-03-16 08:07 | alexy | Note Added: 0001345 | |
2008-03-17 00:31 | Zuz | Note Added: 0001357 | |
2008-03-22 14:20 | alexy | Relationship added | has duplicate 0000213 |
2008-11-14 18:23 | alexy | Note Added: 0001960 | |
2009-04-05 12:52 | alexy | Note Added: 0002892 | |
2009-10-23 12:24 | alexy | Note Added: 0004317 | |
2009-10-23 15:19 | DiRTy_GaRRy | Note Added: 0004324 | |
2009-10-23 15:22 | alexy | Status | new => closed |