| ! | Данная информация предназначена только только для IT-специалистов по системной интеграции модулей БИОСОФТ-М. (см. Руководства пользователя к программным продуктам) |
Реализацией внутренней логики виртуализациии путей занимается класс Islib virtfs доступный только выборочному низкоуровневому коду (SEMIPUBLIC).
Приложениям при обычной работе с файлами не нужно беспокоиться о трансляции путей между внутренним потрабельным представлением их в Islibи особенностями файлов данной платформы. Такая трансляция, одновременно с проверкой корректности доступа, автоматически выполняется всеми функциями Islib получающими path, а так же низкоуровневыми инкапсуляторами как CFileHeap из ExtraSys и проч.
Связанные с этим системные классы
Трансляция виртуального пути в непортабельный реальный это приватная низкоуровневая операция доступная только системному коду и включает декларацию прав доступа к соответствующим файлами и директориям. Недостаточное ограничение прав при вызове этой функции приводит к хаосу и анархии снижающим равиваемость кода.
ospath ospathReal;
if (!virtfs::GPermitPath(
virtfs::F_Permit_..........,
virtfs::F_Permit_..........,
virtfs::F_Permit_..........,
pathVirtual,
out ospathReal,
out out_sError))
{
rASSTR(out_sError);
return out_sError == "";
}Приложениям запрещено получать полные абсолютные пути извне за исключением использования для этого публичных функций Islib возвращающих всякие системные директории и корневые папки для прикладных данных и статических ресурсов.
На низком уровне virtfs::GVirtualizeLocalOsPath() формирует виртуализованный путь к корневой директории из непортабельного пути текущей платформы. Тот факт что эта функция сработала без ассертов не означает что последующий доступ к данному пути будет разрешен GPermitPath().
Пути в path теперь содержат некие текстовые строчки с неопределенным синтаксисом, определяющим либо
Непортабельные низкоуровневые пути обрабатываются ospath запрещенным для обычных приложений.
| ! | Приложениям запрещается подразумевать знание о внутреннем формате виртуального пути, в т.ч. как обозначаются логические диски, какой символ разделяет директории и вообще слеш это какой то или нет. |
Единственное знание о синтаксисе путей которое должно быть явно прописано в приложении это то что расширение файла начинается с точки. Это всегда будет интерпретироваться правильно в любых системах. Кроме того точка может использоваться и в других целях в именах файлов (как при обозначении номера версий). Никаких слешей и двоеточий в приложении быть не может и ожидать их наличия или отсутствия в сформированных pathнельзя.
Приложение должно очень осторожно использовать GetFolder, GetParentFolder только на сформированных им путях или не использовать никогда вообще. Нельзя подразумевать что системный path который вернула системная функции содержит какую то предсказуемую цепочку директорий и можно подняться на уровень выше. Например взять системный GGetMyDocumentsFolder() и пытаться зайти в его GetParentFolder! Очевидно что это операция приводит к какому то катастрофически непортабельному результату. Эта операция может и не работать вообще если Islib использует макросы внутри path и GGetMyDocumentsFolder() вернет скрипт вида "<MyDocuments>" а GetPatientDataFolder(): "{drive:c}{dir:<Patients@Data>}" где просто нет компонентов на которые приложение может что то разложить.
Синтаксис виртуальных путей будет меняться в будущих версиях. Может быть разным для разных платформ (что не снизит портабельности приложений использующих только законные функции).
| ! | Хранение абсолютных путей в файлах между разными сессиями и передача их между машинами по сети или иначе запрещена! |
Полный абсолютный путь, включающий логический диск (не обязательно только в Windows) должен формироваться динамически на основании других прикладных данных в приложении а не хранится полностью однажды сформированным. Хранить приложение может только относительные компоненты как имена файлов и папок из которых потом полный путь составляется в рамках каждой сессии приложения перед доступом к файлу в данной системе.
Не определено чувствительны ли path к разнице заглавных и прописных букв. Все пути субдиректорий и файлов должны задаваться в одной канонической форме, унифицироваться именованными константами и не подразумевать ни алиазности разных регистров ни возможности создать два файла отличающихся регистром букв. Будущие версии библиотек могут начать блокировать такого рода неоднозначные файловые операции даже если они корректны в какой то ОС.
Не определена. Может изменится в будущих версиях. Возможно будет введена гарантия постоянного разделителя субдиректорий, однако операция сравнения двух path на совпадение по любому опасная в зависимости от контекста, платформы, чувствительности к регистру и т.п.
Для удобства при выводе path средствами UniversalView путь обретает более читабельный синтаксис текущей ОС (для Windows появляется двоеточие отделяющее диск, которое однако выглядит своеобразно).
Корректное отображение виртуализированных путей для пользователя
Пока все спецификации дисков заменяются на виндусный формат "c:\" для постоянства логов.
Между нашими Islib-процессами абсолютные виртуальные пути path (не ospath) можно передавать любым способом. Через экспозицию и Interproc или в командной строке. Девиртуализация с верификацией будет сделана процессом, непосредственно выполняющим файловую операцию.
Это совместимо и с консольными Consex-based процессами. Они работают с виртуальными путями.
Для не-Islib внешних приложений потребуется обязательная девиртуализация пути path с проверкой прав доступа согласно тому как внешнее приложение будет этот путь использовать.
Эта категория в данный момент пуста.