Разбор значений и свойств

[sfaqer]

При разборе правил, каталоги для значений и свойств создаются с именем кода элемента (1, 2, 3... 39 т.д.), хотелось бы видеть в наименовании каталога наименование значения\свойства, на текущий момент визуальный поиск конкретного элемента затруднителен.

[otymko]

Надо подумать как сделать. Для значений это можно реализовать. Для свойств уже проблема.

[otymko]

@sfaqer Например это может выглядеть так:

[otymko]

Формат имени:
"[ПорядковыйНомер] " + НаименованиеЭлемента

[otymko]

@sfaqer
Можно попробовать: https://github.com/otymko/gitrules/releases/tag/0.2.2
P.S. для установки:
opm install -f path/to/file

[otymko]

Вытекающая проблема -> длина путей увеличена и теперь:

[sfaqer]

@otymko
Столкнулся с проблемой аналигочной

В недрах ишуйтрекера уноскрипта есть даваний ишуй:
EvilBeaver/OneScript#67

Я так понимаю каких то путей обхода нет.
Можно сократить некоторые очевидные наименования (ПравилаКонвертацииОбъектов -> ПКО, ПравилаВыгрузкиДанных->ПВД), так же можно перед сохранением проверять длину пути итоговую, и обрезать в наименовании например приёмник свойства.

[otymko]

@sfaqer проблема в том что у меня какой-то ПКО может лежать по следующему путь в конвертации:
Документы -> ЕГАИС -> Версия 1 -> Остатки ЕГАИС и т.п.

Большую часть пусти будут все равно занимать наименования свойств как в моем примере. Поэтому из-за ограничения windows мало что можно сделать -> Наименование группа + Наименования свойств очень длинными получаются.

[sfaqer]

@otymko я так понял это не ограничение windows, а ограничения дотнета который внутри уноскрипта, но в нашем случае это ничего не меняет.
В любом случае добавить какую либо проверку на длину пути стоит, и как либо его сократить.
Насколько я понимаю мастер сейчас тоже будет падать, если будет достаточно большая иерархия каталогов в ПКО, даже если свойства\значения будут идентификатором.

[otymko]

@sfaqer Да, если иерархия будет больше чем 260 символов то и мастер упадет. Я проекты делаю обычно в 1-2 папках от корня диска.

Надо ждать решения от oscript.

[bf0rce]

Проблема длинных путей решается установкой ключа реестра (Только для Windows 10, 1607) и перезагрузкой:
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled = 1 (Тип: REG_DWORD)
https://habr.com/post/307186/

[otymko]

@bf0rce обязательно на днях попробую!

[bf0rce]

@otymko, из подробностей могу указать следующее.

1. При обращении к файлам и каталогам из под OneScript будет ошибка.
2. Ошибку можно обойти, если создавать каталоги из записывать файлы, например, через comОбъект FileSystemObject. Видимо, там напрямую идет Windows API (или как там это называется).
3. Придется еще сделать настройку git config --system core.longpaths true, иначе сам гит тоже может ругаться.
4. При запуске кода внутри платформы правила разберутся нормально без ошибок.

[ViktorErmakov]

Добрый день, коллеги!
Скажите, а какие то работы идут по исправлению ситуации с длинной пути 260 символов? Я не могу разложить правила уже месяц))

[bf0rce]

На данный момент те способы, о которых я писал выше не работают. Мы свои проблемы пока обходим локальными вызовами команд PowerShell. Он с длинными путями, как оказалось, работает без ошибок.

[ViktorErmakov]

Можете дать какую то инструкцию, или в статье по разбору правил выложить к примеру?
Я лично забросил хранить правила в гите с тех пор, т.к. не знаю как решить данную проблему.
Получается что проект этот для меня немного умер.

[bf0rce]

Собственно, инструкции нет. Нас пока спасают просто топорные вставки кода, наподобие такого.

	ЗапуститьПриложение("PowerShell.exe -WindowStyle Hidden -Command ""New-Item -ItemType Directory -Force -Path '" + ОбъединитьПути(ТекущийКаталог(), КаталогКоллекции) + "'""",, Истина, КодВозврата);
	Если КодВозврата > 0 Тогда
		ВызватьИсключение("");
	КонецЕсли;

Ну а текстовые файлы пишутся через объект ADODB.Stream. Он тоже работает без проблем с длинными путями.