Импорт сессий из версии под Far 2.1

[shadowlmd]

Хотелось бы иметь возможность импортировать сессии, сохранённые в плагине под Far 2.1 (в реестре). Раньше можно было старые сессии импортировать через NetBox commands, теперь я там ничего подобного не нашёл.

[VictorVG]

Технически это возможно, но реально вам потребуется экспортировать ключ Реестра, если потребуется то отредактировать некоторые значения и иструментами миграции RegScript -> XML перевести их в формат .fafconfig (XML), а после выполнить из командной строки far /import .farconfig . Иного способа в силу различия механизмов хранения настроек и внутренней архитектуры Far2 и Far3 я на данный момент не вижу.

[shadowlmd]

А работать с реестром напрямую плагины под Far3 не могут?

[AnrDaemon]

Могут, но в Far решили избавиться от реестра. Видимо, им там не нашлось, чем ещё заняться... Вообще, я бы предпочёл хранить все SSH сессии в одном ключе, чтобы иметь к ним доступ из PuTTY, WinSCP и NetBox одновременно.

[shadowlmd]

Стало быть, можно научить плагин импортировать старые настройки из реестра? Это было бы проще и удобнее, чем предложенное выше колдунство.. :)

[AnrDaemon]

Можно. Вот только ради одноразового действия никто этим заморачиваться не будет.

[shadowlmd]

Ясно. Раньше просто была такая функция, не понятно, зачем убрали.

[VictorVG]

Причины переноса настроек из Реестра (а это сама по себе БД) в локальные БД объективны и просты - БД Реестра при разрастании резко снижает быстродействие ОС в целом, раз, на её размер существуют системные ограничения два, её использование требует для переноса настроек ПО как раз того, заведомо нетривиального "колдунства" о коем вы говорили выше - три.

А что касается импорта сессий, то тут вообще просто - способы хранения и формат записи сессии в NetBox 1.x и 2.x разный, а как правильно заметил AnrDaemon в данном случае перенос сессий это операция редко используемая, а потому её реализация хотя технически возможна, но код который это сделает нет смысла встраивать в основную программу. Если данная операция у вас выполняется часто, тогда можно написать для неё автономный модуль или скрипт, а для разовой операции овчинка выделки не стоит.

AnrDaemon

Может вы бы лично это и предпочли, удобно, не возражаю, но как быть с вероятным случаем общей записи когда два или более клиента одновременно попытаются её модифицировать в то время как другие её читают? Да, на уровне ОС этот конфликт разрешён, но для приложений он приведёт к их сбоям, а потому я считаю что данная идея "сырая", т.к. её реализация будет излишне сложной как в техническом так и в алгоритмическом плане.

[AnrDaemon]

При разрастании до каких величин, какое именно быстродействие. Пожалуйста, раз уж сказали "А", говорите и "Б". Или вы просто пересказываете околотехнические статьи "о том, как в виндах всё плохо"? Про то, что существуют как встроенные шататные, так и сторонние стредства уменьшения размера БД реестра, говорить не хочется - это просто само собой разумеющийся факт. А для переноса настроек в пределах домена вообще никакого колдунства не требуется. А за пределами вопрос стоит уже совсем иначе.

[VictorVG]

Ну, конечно пересказываю, как иначе.:) А что до конкретных цифр, должен вас разочаровать - для каждой ЭВМ они свои будут ибо нет одинаковых как килограммы систем, да и я за более чем тридцать лет работы с ними таковых увы, не видел. И разница будет не в винтике в кожухе, а в работе комплекса в целом даже если вы поставите в них одинаковые узлы. Не просто так в ТЗ на проектирование ЭВМ, а я как инженер-системотехник их видел не мало не пишутся точные цифры быстродействия, а пишется "Быстродействие, не менее ..." ибо оно зависит от многих случайных факторов от температуры узлов и разброса их параметров до настроек конкретной ЭВМ. Так что ваши начальные предпосылки в этом смысли не корректны.

А что касается встроенных ограничений на размер БД Реестра в ОС семейства WINNT, то по памяти с ходу: NT 3.1 Workstation - 32 Mb, Advanced Server 56 Mb, WinNT 3.50 - 4.0 Workstation - 64 Mb, Server 96 -128 Mb, 2000 Workstation/Server 96/128 Mb, XP/2003 - 128/160 Mb, Vista/7/2008/2012 256 Mb. Ваши системы укладываются в эти пределы размеров БД? Если она больше время её отклика нелинейно возрастает, и время реакции ОС возрастает с 150 - 200 мс до десятков и сотен минут. В большинстве случае это не допустимо, а в системах реального времени и максимального быстродействия OC семейства WINNT слишком мало и они там вообще не применяются, это если забыть про их низкое время наработки на критический сбой - стараниями Микрософт оно снижено с 3,5 лет у NT 3.1 до 1,2 лет у Windows 7/8/2012 ибо иначе она потеряет добрую треть своих доходов получаемых за счёт платной техподдержки своих продуктов.