Мысли вслух - консольный colorer.exe и поиск catalog.xml по относительным путям или симлинками

[VictorVG]

В текущей реализации (Git 70a2ebe ) ключ -c позволяет указать только абсолютный путь, но симлинки или относительные пути не обрабатывает, а было бы не плохо и их разбирать. С относительными путями вроде понятно - указаны относительно текущей директории, только смотрим нет ли в начале "..", если есть поднялись по дереву выше, отбросили первые три байта строки смотрим дальше, если надо повторим переход, если нет, то просто идём вниз по дереву до N-1 уровня и ищем catalog.xml на N. То с симлинками проще - переходим по нему и GetCurentDir() - адрес наш, смотрим есть ли тут база.

Почему бы нам не снять себе данное ограничение? Кстати аналогичная "бяда" имеет место и у Wget -если указываешь путь к файлу сертификатов то надо указать абсолютный или "Путь не найден", но там сиё правится, а нам зачем абсолютные пути? Искать где ошибся при их вводе?

[ctapmex]

с относительным путем понял. по симлинку можешь привести пример когда не работает?

[VictorVG]

Да. Создаём симлинк на тот же catalog.xml и указываем его в ключе -с - в ответ получаем сообщение об ошибке, хотя и не ждём его.

[ctapmex]

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

[VictorVG]

Симлинки удобны, ну потребуются - можно сделать..

[ctapmex]

по поводу симлинков.
твой пример- все схемы лежат где-то "глубоко". ты создаешь симлинк на catalog.xml и кладешь его где-то рядом. colorer должен в итоге работать с тем что "глубоко".
другой пример- есть две папки base1 и base2 . в base2 свой немного отличающийся набор hrd/hrc. Но catalog.xml это симлинк на файл в первой папке. для удобства, один файл на все каталоги.
оба примера легитимны, или есть ошибка ? если оба легитимны, то как colorer должен понимать, что ему делать - идти по симлинку или нет?

[VictorVG]

Во втором случае неточность - симлинк по природе это UNC-указатель на объект и не может указывать на два и более объекта одновременно, а потому если в первом случае мы идём по UNC пути к нужному catalog.xml и там читаем схемы, то во втором нам нужно выбрать какой из двух объектов нас интересует? Потому тут нужен аргумент комстроки или запрос к оператору, а лучше пара запрос и аргумент комстроки с приоритетом на запрос к оператору - пусть человек принимает решение что ему в данный момент надо и отвечает за него, а аргумент команды работает как настройка по умолчанию.

[ctapmex]

а если копнуть дальше? если не только catalog.xml является симлинком, но и часть hrc файлов ? или даже entity из catalog.xml.
возможно я усложняю всё, но если делать работу с симлинками то надо понять как.

1. обработка симлинка только для catalog.xml
2. обработка симлинка для catalog.xml и его entity
3. обработка симлинка для всех файлов
   кажется, что сделав 2 и 3 вариант можно нарваться на проблемные кейсы, когда кто-то реал свою задачу. как в моем примере выше. С другой стороны всем не угодишь, и надо решать конкретную задачу

[VictorVG]

По идее есть общее решение - если мы встретили симлинк (смотрим его файловые атрибуты - у симлинка будет стоять атрибут Repairs point) , то идём по нему проверяя факт существания таргета - отсутствие таргета при переходе по силинку вызовет системную ошибку с кодом 0х00000002 ("Файл не найден" или команда attrib скажет "Конечный объект символической ссылки object не существует" если мы переместили таргет в иной, по сравнению с первоначальным каталог), что не приведёт к удалению симлинка как объекта, и если его таргет найден, то дальше работать с ним как с обычным объектом находящимся по указанному симлинком пути, иначе использовать аналогичный локальный объект по умолчанию.

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

Что до вариантов 2 и 3 - по моему, они излишне трудоёмки, и я бы ограничился вариантом 1 модифицировав его так:

Если на catalog.xml указывает симлинк, то проверяется факт существования catalog.xml по пути указанному симлинком, а пути к конфигурационным файлам записанным в нём считаются относительными по отношению к пути по которому расположен catalog.xml и могут быть харлинками или указывать на реальные файлы но не могут быть симлинками на них.

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

[VictorVG]

По идее должно сработать, попробую как освобожусь.