[WFX] VirtualPanel - временная панель для ТК (Unicode)

[Вахмурка]

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

Этот метод проверен на File Redirector - в сетевом окружении я меня аж 4 виртуальные директории, ссылающиеся на один и тот же wfx-файл, скпированный в разные физические директории.
В рамках процесса постепенного отказа от File Redirector и перехода на Virtual Panel я попытался проделать с последней тот же трюк и... обломался. При попытке регистрации нового файла (переименованного и помещенного в другую директорию) ТС предлагает мне имя Virtual Panel. Даже если я меняю его, оказывается, что созданные директории сетевого окружения полностью идентичны, то есть ссылки, положенные в одну из них, автоматически возникают в другой, причем настройки второго (не Virtual Panel) плагина тупо игнорурются, а единственный раздел инишника получает название Virtual Panel, хотя сам плагин назван по-другому. Из этого я заключаю, что имя ТС вытаскивает из wfx-файла (и оно таки-да там есть). Можно ли без этого обойтись? Почему ВП должна называться именно Virtual Panel? В конце концов, можно тупо изменить wfx-файл (ведь это, если я правильно понимаю, просто dll, и с помощью редактора ресурсов он редактируется).
Не кажется ли тебе, что это следует изменить? То, что это можно сделать, доказано File Redirector'ом (остальные не проверял). Мне думается, что при активном использовании ВП может и должна возникать необходимость иметь несколько ВП для разных целей.
Следующий шаг будет состоять в том, что остальные wfx-файлы являются жесткими ссылками на основной. Далее для каждого из них обычным копированием создается свой ini-файл, если мы, конечно же, хотим разные настройки, и своя база ссылок (в терминах Virtual Panel - "автозагружаемое состояние"), и свой протокол.

Преимущества:
1. Экономия дискового пространства:
2. При обновлении плагина (а VP обновляется чуть ли не каждый день ) другие плагины обновляются автоматически.

Недостаток один - NTFS.

[MVV]

В рамках процесса постепенного отказа от File Redirector и перехода на Virtual Panel я попытался проделать с последней тот же трюк и... обломался. При попытке регистрации нового файла (переименованного и помещенного в другую директорию) ТС предлагает мне имя Virtual Panel. Даже если я меняю его, оказывается, что созданные директории сетевого окружения полностью идентичны, то есть ссылки, положенные в одну из них, автоматически возникают в другой, причем настройки второго (не Virtual Panel) плагина тупо игнорурются, а единственный раздел инишника получает название Virtual Panel, хотя сам плагин назван по-другому. Из этого я заключаю, что имя ТС вытаскивает из wfx-файла (и оно таки-да там есть). Можно ли без этого обойтись?

Эх, сразу видно, не в теме ты. А конкретно - предложение F. Разумеется, имя по умолчанию берется из INI, я возвращаю его в FsGetDefRootName. А далее, никакой экземпляр FS-модуля не знает, под каким именем он зарегистрирован в ТК. Как раз с учетом возможности иметь несколько независимых панелей я и предлагал расширить структурку, передаваемую модулю при инициализации и добавить в нее поле с названием конкретного экземпляра FS-модуля (тогда можно было бы вообще иметь всего 1 VirtualPanel.wfx и использовать любое число экземпляров в ТК, т.к. они бы использовали разные блоки конфигурационного файла).
Но решение проблемы уже есть - и есть оно (как ни странно ), в Readme-файле:

Путь к файлу конфигурации ТК сообщает модулю при инициализации. Если этого не было сделано (например, версия программы ниже 5.51) или существует INI файл с именем модуля в его папке, этот файл будет использоваться как файл конфигурации.

Т.е. создаешь пустой VirtualPanel.ini (или копируешь уже настроенный) рядом с VirtualPanel.wfx и перезапускаешь ТК (или выгружаешь модули) - и этот экземпляр VP будет работать с этим конфигом (кстати, в обсуждении твоей статьи вроде уже всплывал вопрос нескольких конфигов, но по другому поводу), и читать путь к дефолтной базе из него.

А твой FR всегда использует INI в его же папке, и тут без вариантов, и плевать ему на разрешения и т.п.

Кстати, панели модулей из разных папок, но с общим конфигом, не так уж и идентичны. Загружают они один конфиг, сохраняют его хором в одно место, но пока они все загружены, у каждого своё содержимое - просто читать и писать его им в одном месте, потому победит тот, кто придет к финишу последним.

[Вахмурка]

Да, я не в теме. Та ветка показалась мне чересчур специфической (да она и предназначена в первую очередь для Гислера, а во вторую - для плагинописцев).

читать путь к дефолтной базе из него.

Это я уже экспериментально выяснил. Тут ключевое слово - "дефолтной". Меня не устраивает путь %TEMP%\VirtualPanel.lst хотя бы потому, что все %TEMP% у меня при загрузке Винды очищаются (иначе там по принципу идеального газа - занять все доступное пространство) начинает скапливаться мусор.
Если я правильно понял, что при текущем состоянии ТС нельзя иметь произвольное число Virtual Panel'ей, каждая со своими нстройками? Если это не так, распиши для тупых, как этого добиться.

А твой FR всегда использует INI в его же папке, и тут без вариантов, и плевать ему на разрешения и т.п.

Я переформулирую вопрос: ты не считаешь такой подход разумным?

[MVV]

Сейчас принято разделять программные папки и папки настроек - и я с этим в принципе согласен, мухи отдельно, котлеты отдельно. Для того ТК и сообщает модулям путь к конфигу, чтобы они не тулили его куда вздумается, а хранили в одном месте.

Я же написал, что если у каждого VirtualPanel.wfx рядом будет лежать VirtualPanel.ini, то у каждого будут абсолютно независимые от остальных настройки - если ты, конечно, не будешь в каждом указывать путь к базе по умолчанию одинаковый. Под дефолтной я подразумевал прописанную в параметре DefFileList того конфига, который использует отдельно взятый экземпляр - т.е. у каждого может быть свой.

[Вахмурка]

Ага, теперь понял. То есть нельзя менять имена VirtualPanel.wfx и VirtualPanel.ini, верно? Таким образом, мне удалось добиться существования двух независимых VirtualPanel'ей.
Но я продолжил эксперименты с жесткими ссылками. Создав еще одну физическую директорию, я создал в ней жескую ссылку на один из VirtualPanel.wfx, а инишник и базу просто скопировал и изменил. Если я правильно понимаю жесткую ссылку, то для ТС новый файл имеет такие же права, как и просто скопированный. Только операционная система и специальные утилиты и плагины (для создания жесткой ссылки я использовал NTFSlinks от CaptainFlint'а, а для определения числа ссылок - плагин NTLinks от некоего MVV ) различают просто файл и жесткую ссылку. Только вот ситуация повторяется: настройки у плагинов разные, но база того, кого я создал вторым, вообще не создается, а вот иконка, напротив, берется его!
Что-то я туплю. Напомню, хочется создать кучу ВП и автоматически обновлять все плагины, физически обновляя лишь один.

[MVV]

В принципе, ты можешь и менять имя файла конфигурации, но толко вместе с именем модуля (хоть в одну папку десяток VirtualPanelX.wfx и VirtualPanelX.ini) - я вызываю функцию GetModuleFileName, ищу последнюю точку и приписываю расширение, т.е. получаю путь к конфигурационному файлу в той же папке и с тем же именем, но с расширением INI.

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

При отладке я держал в директории Debug персональный конфиг - и все работало нормально, персональные настройки и персональный файл базы. Щас я потестирую с жесткими ссылками.

Ага, создал я кучу файлов (по 5 штук) в одну папку, каждому назначил свой файл базы, кинул в каждый по разному файлу, перезапустил - все работает.

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

Вывод - обдурить систему, заставив ее подключить кучу одинаковых библиотек, образованных жесткими ссылками, не удается. Видимо, система идентифицирует библиотеки не по их полному пути, а по внутреннему индексу (кстати, это объясняет, почему можно файл загруженной библиотеки переносить в любое место на диске), и тупо возвращает его же дескриптор вместо того чтобы загружать в память второй модуль. Process Explorer также показывает, что загружен только один из них - тот, в чью папку ты заходишь в первую очередь.

Кстати, если я, скажем, копирую фильм, и создаю ссылку на недокопированный файл, я его даже удалить эту вторую ссылку потом не могу, пока копирование не завершится.

[Вахмурка]

Спасибо, теперь все ясно. Но, боясь показаться настойчивым, я снова задам тот же вопрос: если созданы N Virtual Panel'ей (с разными базами, конфигами и протоколами), и ты выпустил очередную версию, нельзя ли свести обновление к замене одного, а не N файлов? Если нет, то можно за полминуты нацарапать батник, заменяющий все N штук, но сомневаюсь, что это по силам всем пользователям Virtual Panel. Так что если ты обеспечишь такую возможность (используя свойства NTFS), это только добавит очков твоем детищу.

[MVV]

Нет.

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

Единственный способ узнать, что была загружена еще одна копия этого же модуля - ловить событие DLL_THREAD_ATTACH в функции DllMain. Кстати, ТК при загрузке каждого экземпляра этого модуля вызывает FsInit и FsSetDefaultParams - что не есть хорошо, т.к. заставляет грузить параметры, очищать список и читать его из конфига еще раз, а еще один побочный эффект - что номер WFX-модуля будет равен номеру последнего загруженного. Но далее, например, при вызове FsFindFirst уже будет невозможно понять, для которого из экземпляров ТК вызвал функцию (номер модуля сообщается только один раз, при вызове FsInit/FsInitW). Поэтому все-таки еще раз нет.

Что мешает создать внутри одной временной панели несколько виртуальных папок и использовать их как отдельные панели? Заодно можно будет иметь общую папку для скриптов, так что это может оказаться даже удобнее.

[Вахмурка]

Да нет, ничего не мешает. Разве что не очень убедительные соображения. Например, такое: по ошибке стерта база. Одно дело - потерять одну из многих, другое - одну на всех. ("Не надо класть все яйца в одну корзину").
Второе - просто привычка. Третье - раз уж Virtual Panel любезно предоставляет возможность использовать произвольные иконки и для папок, и для удаленных объектов, было бы забавно иметь разные иконки в разных Virtual Panel'ях. Четвертое - при слишком больших объемах базы время ее загрузки может быть весьма значительным. Если мне нужно загрузить ссылки на 10 файлов, то нет смысла ждать, пока загрузятся 10000, заведомо не нужные...
Поднапружившись, я приведу еще "полстолька" аргументов. Но, раз уж такой возможности нет, придется остановиться на варианте: "много плагинов + батник обновления".

[MVV]

Понимаю, что надоел уже ежедневными обновлениями, но таки выложу. Кто не хочет - может не качать. Причина странного переключения фокуса на левую панель с правой при входе в архив по Shift+Etner, похоже, крылась в том, что ТК не учитывает размер переданного блока данных с командой изменения текущего пути, и ищет флаги команды уже за пределами переданного буфера. Проблему решило увеличение размера передаваемого блока на 1 (там как раз шел нулевой байт, записанный функцией wsprintf).

VirtualPanel 1.0.0.408:
+ Shift+Enter позволяет перейти к файлу или войти в архив в новой вкладке (повышена стабильность)
+ новое ключевое слово script для команды ifcond (проверяет, является ли файл скриптом)

[lsched]

новое ключевое слово script для команды ifcond (проверяет, является ли файл скриптом)

Спасибо, все работает. Скрипт для удаления ссылок на несуществующие файлы (рекурсивный) :
<add \>lost_delete {<for %%f . * { <ifcond "!script && !valid @ %%f" { <del /d "%%f" } } <for /d! %%d . * { <cd "%%d" <exec \>lost_delete } }
Жаль только, что пустые папки не удаляются.

Синтаксис команды ifcond в описании не соответствует реальному. Попрежнему работает конструкция "<expression> @ <virtual_path>", а не {<expression> @ <virtual_path>}, как написано в readme и в справке.

[MVV]

Да, работает. Параметры, содержащие пробелы, можно заключать и в кавычки. Но фигурные скобки были введены специально для заключения в них параметров, содержащих вложенные параметры (по кавычке не виден уровень вложенности - пока я не додумался до фигурных скобок, это реально огорчало меня - поди пойми, зачем стоит кавычка - чтобы открыть новый параметр, или закрыть текущий), а также - для того, чтобы понять, что попавшийся в строке символ < является частью параметра, а не началом следующего скрипта. Поэтому, если знак меньше в выражении отсутствует, оно будет работать и в кавычках, но вполне можно заключать все параметры, требующие кавычек, в фигурные скобки - это будет работать ничуть не хуже.

В Readme указано, зачем заключать скрипты в фигурные скобки:

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

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

[lsched]

вполне можно заключать все параметры, требующие кавычек, в фигурные скобки - это будет работать ничуть не хуже.

К сожалению, к ifcond это не относится. У меня эта команда работает только когда параметр <условие @ путь> заключены в кавычки. Как только меняю кавычки на фигурные скобки - полная тишина.

[lsched]

MVV
Посмотри

[Вахмурка]

2MVV
Пожелания:
1. Ограничение размера протокола (как это сделано в ТС). Например, так: при достижении заданного размера (или/и по истечении заданного времени) основной протокол получает расширение bak, предыдущий протокол с таким расширением удаляется, основной начинается с нуля;
2. Комментарии. Файл с предлагаемым именем >descript.ion хранится в той же виртуальной директории, где и ссылка на комментируемый файл;
3. Экспорт скриптов из ВП простым перетаскиванием.