View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002552 | Far Manager | Plugins API | public | 2014-01-03 13:37 | 2014-01-22 19:30 |
Reporter | SEt | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 3.0 | ||||
Summary | 0002552: AnalyseW и каталоги с точками на конце | ||||
Description | AnalyseW отдаёт плагинам имена вида "c:\dir.\file", которые совершенно бесполезны, так как CreateFile их не открывает. Если по Info->FileName сделать FSF.ConvertPath(CPM_NATIVE, ...) или на панели сделать cd "\\?\c:\dir." то всё работает. Не очень хочется в каждом плагине на каждую операцию AnalyseW делать FSF.ConvertPath(CPM_NATIVE, ...). Хорошо бы или всегда отдавать NATIVE путь, или хотя бы в случаях, когда CreateFile по-другому не может. | ||||
Additional Information | Такие каталоги имеют и другие проблемы. Например, в нём невозможно исполнить консольные команды (dir,..) даже если у такого каталога есть короткое имя и в него перешли по короткому имени. | ||||
Tags | No tags attached. | ||||
Build | |||||
|
Что-то нет реакции... Конкретно предлагается в файле plugins.cpp заменить ConvertNameToFull(*Name,strFullName); на strFullName = NTPath(*Name); |
|
И сломать всех, кто к этому не готов? |
|
Очевидно, изменение нуждается в тестировании. У меня, вроде бы, никому хуже не стало, а с такими путями автоматически заработали и другие плагины. |
|
> Не очень хочется в каждом плагине на каждую операцию AnalyseW делать FSF.ConvertPath(CPM_NATIVE, ...). Также не очень понятно, почему так сильно не хочется. |
|
Потому, что незачем делать одно и то же в каждом плагине, когда это может сделать один раз фар. Хотя бы с точки зрения скорости. А также с точки зрения работоспособности плагинов, авторы которых не сделали данного хака. Давайте конструктивное обсуждение: чем плохо новое поведение конкретно? Только не надо о потенциальных проблемах не пойми где. Хорошо оно тем, что поддержка подобных каталогов в плагинах существенно улучшается "из коробки". |
|
Данный хак не является серебрянной пулей. Для полноценной работы с нестандартными именами плагин не должен закладываться на MAX_PATH, не должен использовать current directory и определённые функции winapi и должен использовать нативный формат путей. Это как бы дофига работы (которую нужно делать в каждом плагине) и одна строка тут погоды не сделает. Конструктивное обсуждение: желание выдавать нативный путь только в одном месте выглядит весьма странно. Почему не везде? |
|
А кто называл это серебряной пулей? Исключительно локальное улучшение, которое позволяет работать с такими каталогами уже здесь и сейчас во многих плагинах даже без их изменения. Я не против светлого будущего, но 1) когда оно ещё наступит; 2) с чего-то же нужно начинать. "Выглядит странно" – это ни разу не конструктивное обсуждение. Где было сказано, что нужно выдавать нативный путь только в этом одном месте? Таких мест может быть много, а в этом баге речь идёт про конкретное место. Здесь представлена конкретная проблема и конкретное решение, а вы ничего конкретного здесь ещё не сказали. |
|
Лично мне не нравятся "локальные улучшения" в стиле "а давайте вот здесь подхачим, а то мне в моём плагине здесь и сейчас неудобно, а остальное как-то пофиг, потом". Если в api продукта в одну функцию приходит x:\path, в другую \\?\x:\path, а в третью ещё как нибудь - то это не локальные улучшения, а бардак. |
|
В моём-то плагине как раз и так всё работает, а изменение направлено на то, чтобы и в остальных работало. По-подробнее про остальное, на которое мне пофиг, пожалуйста. Сначала были ничем не обоснованные заявления, что всё остальное сломается. Потом просто "мне так не нравится". В данную функцию, по логике, должен приходить путь в том виде, в каком его можно применить в CreateFile. Вы на меня свой бардак не сваливайте: здесь разговор про конкретную функцию, а не как вы очень любите "вообще, ни о чём конкретном". Да, вполне вероятно, что и в остальных подобных случаях PluginAPI следует произвести аналогичное изменение, но это мной никогда не отрицалось. Кроме того, необходимость провести изменения абсолютно везде абсолютно одновременно неясна: что страшного в постепенном исправлении кривого API? Мгновенно прекрасным оно никогда не станет. |
Date Modified | Username | Field | Change |
---|---|---|---|
2014-01-03 13:37 | SEt | New Issue | |
2014-01-22 12:56 | SEt | Note Added: 0011728 | |
2014-01-22 13:08 | DrKnS | Note Added: 0011729 | |
2014-01-22 13:14 | SEt | Note Added: 0011730 | |
2014-01-22 13:25 | DrKnS | Note Added: 0011731 | |
2014-01-22 14:05 | SEt | Note Added: 0011732 | |
2014-01-22 14:34 | DrKnS | Note Added: 0011733 | |
2014-01-22 16:49 | SEt | Note Added: 0011734 | |
2014-01-22 18:33 | DrKnS | Note Added: 0011735 | |
2014-01-22 19:30 | SEt | Note Added: 0011736 |