Настройка режима передачи для сервера не выставляется

[HardyBrainOff]

"Настройки передачи даных" -> выставить режим передачи как "Текст" или "Определять автоматически". Настройка работает только при передаче от клиента к серверу. Если передавать от сервера к клиенту, то постоянно стоит настройка передачи как "Двоичный" (Binary), что сильно тормозит работу, когда надо постоянно передавать текстовые данные UNIX->WIN, приходится каждый раз влезать в пункт параметров передачи и переключать триггер. Причем добавленные в настройках плагина в пункте "Определять автоматически" расширения тут сбрасываются на дефолтную строчку, то есть невозможно передать кучу разнородных данных сразу согласно их расширению.

[VictorVG]

Ну, тут я думаю это более разумный вариант так как при передаче данных как двоичных к файлам не добавляется символ EOF который может повредить данные. По моему проще вызвать unix2dos / dos2unix из того же Msys Core Utils для пакетного преобразования переносов строк, чем после кучу бинарников чинить.

[HardyBrainOff]

Эмм... вопрос не в том, чтоб зажать настройку на режим "Текст", а чтоб выставленные настройки плагина применялись к этому окну при передаче от сервера (в старом FTP клиенте FAR-а ж все работало). Непонятна избирательность, так как вызывается по сути одно и тоже окно и, ИМХО, проще сделать его одинаковым, чем дополнительно выставлять для клиента и сервера разные условия. Скорее всего где-то пропущено обращение к выставленным настройкам и они сбрасываются на дефолтные каждый раз при вызове окна. Я б еще понял, если б в рамках одной сессии можно было выставить настройки, но нет. Ну и отличие в режимах не заключается в символе EOF - я специально уточнил для чего это нужно - в UNIX-е в конце строки стоит LF, а WIN-де требуется CR/LF, что при бинарной передаче также портит данные - колоночные файлы слепляются в ком. Если так советовать, то можно тогда дойти до - а поставьте старый FAR и забейте на этот плагин вообще. Ибо иногда надо передать разом 50 файлов, а иногда по паре в час, и получается каждый раз надо бегать к сторонним прогам, потому как просто накопить и конвертнуть все кучей не выход - этими данными пользуются дальше и "конвейер" начинает тормозить.

П.С. Извините, но для меня немного странно на странице багрепов и создания тикетов вести диалог в стиле "это не баг, это фича".

[VictorVG]

В данном случае я для себя пытаюсь понять вашу задачу. Не более того.

[HardyBrainOff]

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

Задача в том, что есть UNIX-сервер, где стоят определенные расчетные программы. Связь с ними через эмуляцию Х-ов в виндах и передача данных в обе стороны через FAR по FTP (стандартная схема для научных организаций). По сути можно через что угодно передавать, напр Файлзиллу, но в FAR-е еще есть удобный текстовый редактор, когда после передачи надо подправить некоторые данные на лету. С компов клиентов на сервер передаются первичные материалы и с него же забираются результаты расчетов. Они в разных форматах как текст, так и бинарники. Причем текста ощутимо больше. В результате, настроив панель в настройках, эти настройки видны только когда я пытаюсь передать что-либо от клиента к серверу. В другом направлении постоянно вызывается дефолтное окно, где постоянно приходится влезать в дочернее окно и выставлять принудительно режим как "Текст". И вот это странно, эта избирательность. Ведь мне не запрещено там поменять настройки, и даже "умный режим" выбора по расширению работает, но до следующего вызова передачи - там опять будет все сброшено, даже если сессия не закрывалась и не было смены папок.

Я вижу как решение проверить откуда происходит заполнение диалогового окна от сервера и перенаправить его на то место, где хранятся настройки. Тут еще такой момент, что неясно куда на самом деле сохраняются настройки - ни рядом инишек нет, ни в реестре записей не нашел. И мб проблема с нарушением доступа к ним из-за паранойи Винды.

[VictorVG]

Задачу понял. В Far 3.0 настройки плагинов сохраняются в БД SQLite3 в каталоге %FARPROFILE%\PluginsData, имя БД NetBox 42E4AEB1-A230-44F4-B33C-F195BB654931.db (значение переменной среды %FARPROFILE% определяется вашим Far.exe.ini лежащем в том же каталоге что и Far.exe) и проблема может быть вызвана её повреждением (плагин к ним чувствителен).

Что бы тут сделал я?

1) зайти на панель сессий NetBox, выделить их и скопировать в любой каталог на противоположной панели. Так мы получим XML файлы с расширением .netbox - резервные копии основных настроек сессий; 2) при незапущенной данной копии Far-а удалил бы БД %FARPROFILE%\PluginsData\42E4AEB1-A230-44F4-B33C-F195BB654931.db чтобы после не использовались заведомо ошибочные настройки; 3) Снова запустить Far, F9, Настройки плагинов, NetBox и там настроить только базовые настройки, прежде всего если используется внешняя PuTTY и пути к её модулям, ShiftF9 ; 4) Запустить Far, вызвать NetBox (он выведет пустую панель сессий), выбрать ранее сохранённые резервные копии сессий и нажать F5 (или перетащить их на панель сессий), согласится с их импортом (такой метод импорта настроек не очевиден, но использовать стандартный far /export default.farconfig , удаление БД, чистка (в редакторе или с помощью плагина FarXML) экспортированного default.farconfig, far /import default.farconfig чревато внесением новых ошибок из-за которых Far может не запустится или после будет сбоить); 5) скорректировать нужные элементы сессий по F4 на панели сессий NetBox; 6) повторно проверить работоспособность сборки;

Возможно, что так мы сможем убрать накопившиеся в процессе работы ошибки и проблема будет решена. Я понимаю, что это дополнительный труд, но думаю что так стоит поступить, особенно если производилось обновление с предыдущих версий NetBox - в процессе его развития было несколько моментов когда менялся формат записей этой БД что сейчас могло вызвать ошибки.

P.S.

В Far 1.х/2.х настройки хранились в Реестре, и там чистка в чём-то проще - вызвать RegEdit, открыть HKCU\Software\Far Manager, найти и удалить там ключ NetBox, а остальные операции (экспорт импорт настроек, их коррекция по месту) выполняются аналогично с Far 3.0.

Я понимаю, что скорее всего эти вещи вам знакомы, но на всякий случай расписал всё подробно - вдруг пригодится?

[HardyBrainOff]

1. У меня нет файла Far.exe.ini, есть только пример с закомментированными строчками - скорее всего все идет по дефолту.
2. В процессе поиска этих домашних папок обнаружилось, что есть две папки (у меня Вин10, но это и на 7ке также): %USERPROFILE%\AppData\Local\Far Manager\Profile\PluginsData %USERPROFILE%\AppData\Roaming\Far Manager\Profile\PluginsData Первая - пустая, хотя на уровень выше там есть какие-то настройки и файлы с .db Во второй есть несколько баз плагинов и искомая в том числе.
3. Удалил, перезашел, выставил только автовыбор режима передачи и добавил пару расширений (FAR даже запомнил предыдущую строчку и подсказал ее в выпадающем списке). Сторонним PuTTY не пользуюсь - там в настройках по дефолту стоят какие-то папки, но их просто не существует.
4. Импортировал сессию, менять ничего не потребовалось, сосбна там только адрес до серва и вбитый лог/пасс.
5. Попробовал вызвать диалог - со стороны клиента все как выставил (Авторежим), со стороны сервера по прежнему дефолтное окно с Бинарной передачей и отсутствием в строке добавленных расширений.
6. Даже попробовал скопировать в первую пустую папку базу плагина - все равно нет.

Дело явно не в базе.

Да, я не написал сразу версию плагина - у меня та, что счас в релизе на сайте 2.4.3. b512

[VictorVG]

@HardyBrainOff

Раз у вас только шаблон Far.exe.ini , то да, настройки хранятся в профиле пользователя. По комментам в этом файле вы можете увидеть где кто находится. Можно попробовать обновить сам плагин. Последняя корректно работающая с RFC-1738 версия 2.4.4.524. Я ей пользуюсь, после работа со схемами адресации URL сломана авторами WinSCP (они игнорируют международный стандарт RFC-1738). У меня она лежит в ./Far3. БД которые вывидели и есть базы настроек Far. Они в них пишутся. Для обновления плагина достаточно скопировать его каталог ./Plugins/NetBox куда-то для резерва и обновить содержимое своего каталога %FARHOME%\Plugins\NetBox содержимым архива с соблюдением разрядности. А после перезапустить Far и посмотреть исправилась ли ошибка.

[HardyBrainOff]

Нет, новее версия не помогла, это где-то сломалось раньше. Нашел на работе комп с FAR 3.0 build 3333, к которому шел плагин версии 2.1.29 build 236 и там настройки подхватываются корректно, правда что-то с файлами локализации и все на англ (ну это не важно). Проверить на каком билде сломалось не могу - тут на сайте только сорцы лежат для FAR 3, а мне собирать нечем (да и забыл я уже все это - лет 15 как назад кодил).

Да, пробовал перетащить плагин со старой версии - крашит FAR при вызове панели по Alt+F1/F2

[VictorVG]

Архив версий могу подкинуть - на моём домашнем сервере лежат:

FarNetBox-2.2.2_Far3_x64.7z FarNetBox-2.2.2_Far3_x86.7z FarNetBox-2.3.0_Far3_x64.7z FarNetBox-2.3.0_Far3_x86.7z FarNetBox-2.4.0_Far3_x64.7z FarNetBox-2.4.0_Far3_x86.7z FarNetBox-2.4.2.443_Git-092d4a57d6_Far3_x64.7z FarNetBox-2.4.2.443_Git-092d4a57d6_Far3_x86.7z FarNetBox-2.4.2.445_Far3_x64.7z FarNetBox-2.4.2.445_Far3_x86.7z FarNetBox-2.4.2.451_Far3_x64.7z FarNetBox-2.4.2.451_Far3_x86.7z FarNetBox-2.4.2.454_Far3_x64.7z FarNetBox-2.4.2.454_Far3_x86.7z FarNetBox-2.4.2.455_Far3_x64.7z FarNetBox-2.4.2.455_Far3_x86.7z FarNetBox-2.4.2.456_Far3_x64.7z FarNetBox-2.4.2.456_Far3_x86.7z FarNetBox-2.4.2.457_Far3_x64.7z FarNetBox-2.4.2.457_Far3_x86.7z FarNetBox-2.4.2.460_Far3_x64.7z FarNetBox-2.4.2.460_Far3_x86.7z FarNetBox-2.4.2.463_Far3_x64.7z FarNetBox-2.4.2.463_Far3_x86.7z FarNetBox-2.4.2.464_Far3_x64.7z FarNetBox-2.4.2.464_Far3_x86.7z FarNetBox-2.4.2.466_Far3_x64.7z FarNetBox-2.4.2.466_Far3_x86.7z FarNetBox-2.4.2.467_Far3_x64.7z FarNetBox-2.4.2.467_Far3_x86.7z FarNetBox-2.4.2.468_Far3_x64.7z FarNetBox-2.4.2.468_Far3_x86.7z FarNetBox-2.4.2.471_Far3_x64.7z FarNetBox-2.4.2.471_Far3_x86.7z FarNetBox-2.4.2.472_Far3_x64.7z FarNetBox-2.4.2.472_Far3_x86.7z FarNetBox-2.4.2.475_Far3_x64.7z FarNetBox-2.4.2.475_Far3_x86.7z FarNetBox-2.4.2_Far3_x64.7z FarNetBox-2.4.2_Far3_x86.7z FarNetBox-2.4.3.483_Far3_x64.7z FarNetBox-2.4.3.483_Far3_x86.7z FarNetBox-2.4.3.485_Far3_x64.7z FarNetBox-2.4.3.485_Far3_x64_vc14.7z FarNetBox-2.4.3.485_Far3_x86.7z FarNetBox-2.4.3.485_Far3_x86_vc14.7z FarNetBox-2.4.3.486_Far3_x64.7z FarNetBox-2.4.3.486_Far3_x86.7z FarNetBox-2.4.3.492_Far3_x64.7z FarNetBox-2.4.3.492_Far3_x86.7z FarNetBox-2.4.3.494_Far3_x64.7z FarNetBox-2.4.3.494_Far3_x86.7z FarNetBox-2.4.3.496_Far3_x64.7z FarNetBox-2.4.3.496_Far3_x86.7z FarNetBox-2.4.3.501_Far3_x64.7z FarNetBox-2.4.3.501_Far3_x86.7z FarNetBox-2.4.3.502_Far2_x86_x64.7z FarNetBox-2.4.3.502_Far3_x64.7z FarNetBox-2.4.3.502_Far3_x86.7z FarNetBox-2.4.3.503_Far3_x64.7z FarNetBox-2.4.3.503_Far3_x86.7z FarNetBox-2.4.3.505_Far2_x64.7z FarNetBox-2.4.3.505_Far2_x86.7z FarNetBox-2.4.3.505_Far3_x64.7z FarNetBox-2.4.3.505_Far3_x64_fix.7z FarNetBox-2.4.3.505_Far3_x86.7z FarNetBox-2.4.3.505_Far3_x86_fix.7z FarNetBox-2.4.3.507_Far3_x64.7z FarNetBox-2.4.3.507_Far3_x86.7z FarNetBox-2.4.3.508_Far2_x64.7z FarNetBox-2.4.3.508_Far2_x86.7z FarNetBox-2.4.3.508_Far3_x64.7z FarNetBox-2.4.3.508_Far3_x86.7z FarNetBox-2.4.3.509_Far3_x64.7z FarNetBox-2.4.3.509_Far3_x64_fix.7z FarNetBox-2.4.3.509_Far3_x86.7z FarNetBox-2.4.3.509_Far3_x86_fix.7z FarNetBox-2.4.3.510_Far3_x64.7z FarNetBox-2.4.3.510_Far3_x86.7z FarNetBox-2.4.3.512_Far3_x64.7z FarNetBox-2.4.3.512_Far3_x86.7z FarNetBox-2.4.3_Far2_x64.7z FarNetBox-2.4.3_Far2_x86.7z FarNetBox-2.4.3_Far3_x64.7z FarNetBox-2.4.3_Far3_x86.7z FarNetBox-2.4.4.513_Far2_x64.7z FarNetBox-2.4.4.513_Far2_x86.7z FarNetBox-2.4.4.513_Far3_x64.7z FarNetBox-2.4.4.513_Far3_x86.7z FarNetBox-2.4.4.514_Far3_x64.7z FarNetBox-2.4.4.514_Far3_x86.7z FarNetBox-2.4.4.516_Far3_x64.7z FarNetBox-2.4.4.516_Far3_x86.7z FarNetBox-2.4.4.518_Far3_x64.7z FarNetBox-2.4.4.518_Far3_x86.7z FarNetBox-2.4.4.519_Far3_x64.7z FarNetBox-2.4.4.519_Far3_x86.7z FarNetBox-2.4.4.521_Far3_x64.7z FarNetBox-2.4.4.521_Far3_x86.7z FarNetBox-2.4.4.522_Far3_x64.7z FarNetBox-2.4.4.522_Far3_x86.7z FarNetBox-2.4.4.524_Far3_x64.7z FarNetBox-2.4.4.524_Far3_x86.7z FarNetBox-2.4.5.526_Far3_x64.7z FarNetBox-2.4.5.526_Far3_x86.7z FarNetBox-2.4.5.527_Far3_x64.7z FarNetBox-2.4.5.527_Far3_x86.7z FarNetBox-2.4.5.529_Far3_x64.7z FarNetBox-2.4.5.529_Far3_x86.7z FarNetBox-2.4.5.531_Far3_x64.7z FarNetBox-2.4.5.531_Far3_x86.7z

[HardyBrainOff]

Вот проверить бы эти - чет мне кажется, что где-то при переходе по минорным версиям потерялось, мб даже сразу с 2.1 на 2.2. FarNetBox-2.2.2_Far3_x64.7z FarNetBox-2.3.0_Far3_x64.7z FarNetBox-2.4.0_Far3_x64.7z А сам FAR не может как-то на это влиять, потому как к новому старый плагин не подошел?

[VictorVG]

Да, если он собран под более ранний чем b4400 билд, то можно получить сообщение об ошибке. Вот, то что вы просили под b4400 и новее (все три версии в общем Zip архиве ):

NetBox_for_Far3_b4400_or_never.zip

Просто распакуйте архив, а там для удобства всё разложено по отдельным версиям каталога FarNetBox.

[HardyBrainOff]

Спасибо. Сразу первый FarNetBox-2.2.2_Far3_x64.7z уже дает такую ошибку. Все таки не может быть это из-за нового билда FARa?

[VictorVG]

Вряд ли. Скорее в NetBox причина. Фар пишет в БД то,что ему передал плагин, и это его логику надо смотреть...

[HardyBrainOff]

Сравнивал версии диффом - в CopyParam.cpp что-то сильно меняли между 2.1.28 и 2.2.0 и мб где-то потом забыли вызвать Assign. Или после вызова опять все занулили. Тяжело разбирать чужой код особенно когда занимался этим лет 10 назад. :)

[VictorVG]

А вот это могло быть. В коде много сходных переделок...

[9-11]

Должно решаться тем же патчем patch.txt, что в #265

[VictorVG]

Добро. Ещё бы FTP починить https://github.com/michaellukashov/Far-NetBox/issues/256 там достаточно критичеая ошибка приводящая к потере данных...