Кириллица в именах сессий вызывает проблемы с FTP

[VictorVG]

Имеем свежую сборку NetBox 3.1.38 ветка Far3 Git rev. c6c2a9d663, Far b4012 r12179 x86, ОС Win7 SP1 x86 ru-RU, шрифт консоли Lucida Console, 15.

На панели плагина создаём новую FTP сессию, задаём все параметры, OK, и вводим её название исключительно кириллицей.

После этого получим проблемы:

1) содержимое данной сессии не сохранено; 2) название сессии сохраняется в непонятной кодировке и выводится плашками:

3) эту сессию невозможно удалить и как следствие этого переименовать если вручную не почистить БД - верхняя (вторичная) запись сессии на скриншоте сформировалась автоматически при попытке переименовать первичную сессию названную кириллицей; 4) если посмотреть содержимое такой сессии по F3 увидим её XML эквивалент:

`<?xml version="1.0" encoding="UTF-8"?>

2.1.38 SFTP%20(SCP) ` хотя вроде мы задавали FTP и это была копия вот этой записи: ` 2.1.38 ftp.rarlabs.com 21 15 2 0 FTP /rar/ No No 0.25000 1 15 Yes ` Может пока укажем как известное временное ограничение чтобы кириллицей в именах сессий не пользовались?

[michaellukashov]

В версии 2.1.38.315 проблема с кодировкой имен сессии решена (я надеюсь). Проверьте плиз. И спрасибо за багрепорт.

[VictorVG]

Собрал 2.1.38.315, проверил, результаты:

1) Проблемы с именованием сессий кириллицей мы можем снять с повестки дня - сессии сохраняются, работают, переименовываются и удаляются;

из свежеотловленных проблем (не знаю стоит ли нам ещё один тикет плодить? мне думается это можно в рамках данного тикета разрешить ибо явно есть какая-то взаимосвязь событий ???):

в билде 315 сломался экспорт импорт / сессий до того работавший в билде 313. Проверка похожая:

F5 на файловую панель и смотрим что получили в XML файле:

на панели плагина имеем сессию RarLabs (FTP):

`<?xml version="1.0" encoding="UTF-8"?>

2.1.38 ftp.rarlabs.com 21 15 2 0 FTP /rar/ No No 0.25000 1 15 Yes

` в билде 313 XML будет иметь то же содержание, только детектор CP вьера укажет что у нас она неверная - не UTF-8, а CP-1251 (это его личный глюк, редактор видит что у нас UTD-8), но нам важно её содержимое. Переходим к билду 315, импортируем сессию, проверяем её XML содержимое нажав на ней F3 и видим потерю данных при операции импорта:

`<?xml version="1.0" encoding="UTF-8"?>

2.1.38 SFTP%20(SCP)

` Если произвести экспорт сессии из билда 315, то в XML увидим аналогичную картину - URL и все настройки кроме названия сессии и протокола не будут экспортированы, в качестве названия протокола увидим только SFTP%20(SCP) даже для WebDAV SVN сессий:

экспорт из билда 313:

`<?xml version="1.0" encoding="UTF-8"?>

2.1.38 sumatrapdf.googlecode.com 80 0 WebDAV /svn/trunk/ No No 1

`

её представление == экспорту билда 315:

`<?xml version="1.0" encoding="UTF-8"?>

2.1.38 SFTP%20(SCP) ` а поскольку мы тут возились с именованием сессий, то я и предполагаю что оба явления имеют общую связь - при правке имён случайно поломался механизм экспорта / импорта. Ну исходя из этой гипотезы я и предложил объединить то что мы видим в едином тикете чтобы устранить эту проблему раз и навсегда и более к ней не возвращаться. Бинарники v2.1.38.315 на которых я тестировал вот: FarNetBox-2.1.38_Far3_x64.7z - https://yadi.sk/d/QNgp0-fMUNipQ FarNetBox-2.1.38_Far3_x86.7z - https://yadi.sk/d/ieY1OR2YUNitv

[VictorVG]

Я сейчас эту же сборку посмотрел на новом билде 4018 где поправлен конвертор UTF-8 -> UTF-16:

drkns 04.07.2014 22:46:04 +0200 - build 3978

1. Внутренний конвертер utf8 -> utf16 некорректно преобразовывал 4-байтные символы.

и может я ошибаюсь выдвигая гипотезу о месте поломки, но мне кажется что поломалась связь "менеджер сессий - SQLite". По крайней мере внешне всё выглядит так, будто менеджер считывает/пишет имя сессии, а её настройки прочитать/записать не может работая только с таблицей Keys, а таблицу Value игнорирует конструируя сессию заново с параметрами по умолчанию. И похоже, что в основе явления лежит изменение формата в базах SQLite 3.8.5:

svs 07.06.2014 11:16:01 +0400 - build 3947

1. SQLite 3.8.5

ибо с настройками проблемы вызванные оптимизацией уже были в билде 3987 (http://forum.ru-board.com/topic.cgi?forum=5&topic=31718&start=5280#13) и мы со skipik несколько дней потратили чтобы понять в чём дело. На всякий случай я экспортировал использованные настройки плагина в XML (формат farconfig) и вместе с его БД положил в архив (7-Zip v9.34 Alpha, LZMA, SOLID, MAXIMUM) https://yadi.sk/d/7Zs2qIOvX9i4e на облако иначе мы можем потерять отладочные данные...

А пока выходит так, что БД настроек нужно удалить и всё набить заново - тогда плагин их увидит, хотя временное решение задачи переноса настроек я нашёл:

1) экспортируем настройки Far в .farconfig 2) удаляем из него все секции <key name="42E4AEB1-A230-44F4-B33C-F195BB654931" description="NetBox"> , затем в секции Sessions <key name="Sessions" description=""> исправляем все старые значения параметра <value name="Version" type="text" value="2.1.хх"/> на <value name="Version" type="text" value="2.1.38"/> 3) far /import .farconfig.

Пляски с бубном, но пока иного решения у нас нет, а это для данной ревизии работает.

[VictorVG]

Собрал свежую сборку 2.1.38.315-fbc9354833 - импорт/экспорт сессий из .farconfig, с панели на панель данные не теряются. Появилась одна мелочь - если экспортировать, а затем удалить БД плагина созданную ревизией 354686b а после выполнить импорт этих настроек из .farconfig, то при удалении любой старой сессии остаётся "хвост" с XML содержимым (на примере учётной записи для RarLabs):

`<?xml version="1.0" encoding="UTF-8"?>

2.1.38 SFTP%20(SCP) ` если удаляем БД и создаём её заново побочных эффектов нет. Ну и для справки - загрузка ЦП по результатам мониторинга Process Hacker 2.34.5432 при копировании ftp://ftp5.gwdg.de/pub/tdf/libreoffice/testing/4.3.0/win/x86/LibreOffice_4.3.0.3_Win_x86.msi :  цена деления шкалы времени 5 с/деление, ЦП iPentium DC E5800 @3,2 GHz (это урезанный по набору команд, частоте шины и кэшу L2 Core 2 Duo): 

[VictorVG]

Собрался только CMake-ом v2.1.38.316-9d83832b2c - бинарники вышли явно больше чем в ночнучках, но собрались, в IDE куча варнингов и в конце сбой построения - логи:

х86 - https://yadi.sk/i/gYRfbBVEXtdu7 х64 - https://yadi.sk/i/6eFrqa_BXte9p

.:( Посмотрел загрузку ЦП для тех же самых файлов с того же FTP - небо и земля:

2,88% << 48,74% что мы видели ранее. Загрузка ЦП снизилась на порядок. Из старых вещей - необходимость пересоздания БД для версий ниже 2.1.38.315 осталась. Пробовал на нашей тестовой БД - подхватывается, но для работы с новой версией не годится, явления те же что описывались выше для ь315..

[VictorVG]

При сборке ревизии b316-c732e1b1f2 в студии она сообщает об успехе, но в каталог ./build ничего не копируется. Судя по логам в проекте опечатка и часть скрипта отвечающая за копирование файлов потёрлась. Вот логи:

NetBox-2.1.38.316-c732e1b1f2_x64.log - https://yadi.sk/i/CmSl0VE3Y2HGM NetBox-2.1.38.316-c732e1b1f2_x86.log - https://yadi.sk/i/ELOTmkWMY2HH8

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

[VictorVG]

Ну, частично отыскал я наши потеряшки - это строки 183:

`

scripts\make_dist.cmd Far3 x86

</PostBuildEvent>`

и 224:

`

scripts\make_dist.cmd Far3 x64

`

они при редактировании случайно потерялись, а потому компилятор и не копирует файлы - каталога -то нет. Поправил на сию тему проект и вот что вышло - https://yadi.sk/d/fukjKTifY6ugd . Единственный кто у меня после коррекции в выходной каталог и соответственно в архив не копируется это NetBox.dll, да и размеры её мне не по душе - для х86 собирается 2677 Кб, х64 - 3841 Кб (заданные в проекте режимы сборки и оптимизации не менял, конфигурация Release)....

[VictorVG]

Я думаю, что нам стоит сей инц закрыть - не знаю, может компилятор или система чудя? CMake собирает - подстроился под него...

[michaellukashov]

ok, давайте закроем.