В документации для boost::filesystem::canonical(const path& p)
указано:
Обзор. Преобразует p, который должен существовать, в абсолютный путь, который не имеет символьных ссылок, точек или точек....
Замечания:! Существует (p) - ошибка.
Следствием этого является то, что если p идентифицирует символическую ссылку, цель которой не существует, функция не работает с file not found
и не возвращает путь.
Это выглядит слишком ограничительным для меня: только потому, что цель ссылки не существует, я не вижу причин, по которым функция не может решить путь этой несуществующей цели. (Для сравнения, absolute()
не налагает такого ограничения.)
(Очевидно, что если символическая ссылка внутри пути нарушена, целевой путь не может быть разрешен.)
Итак, есть ли законное оправдание для этого ограничения?
И даже если есть, нет ли также оправдания для создания варианта функции, который не имеет этого ограничения? (Без такого варианта для получения пути требуется ручная репликация с ошибкой 99% от того, что canonical()
уже делает.)
Я понимаю, что семантические тонкости, существующие между stat()
и lstat()
, одинаково применимы к этому случаю - именно поэтому я считаю, что вариант функции одинаково оправдан.
Примечание. Этот вопрос в равной степени применим к библиотеке std::experimental::filesystem
(n4100), которая основана на boost::filesystem
.
EDIT:
После того, как @Jonathan Wakeley очень хорошо осведомленный ответ ниже, я все еще остаюсь в сущности моих оригинальных вопросов, которые я немного перефразирую:
-
Существует ли техническая или логическая причина, по которой
boost::filesystem::canonical()
требует, чтобы цель существовала? Под этим я подразумеваю, что несуществование цели каким-то образом не позволяет решить путь к канонической форме? -
Если нет, есть ли какая-либо техническая или логическая причина не предлагать вариацию функции, которая отличается только от существующей формы тем, что она не требует, чтобы цель существовала?
-
В преобразовании (как я понимаю, имеет место)
boost::filesystem
в предлагаемый N4100std::experimental::filesystem
, имеет ли это ограничение наcanonical()
после должного рассмотрения или просто "проваливается" 'из определения Boost?
ИЗМЕНИТЬ 2:
Я заметил, что Boost 1.60 теперь предоставляет функцию weakly_canonical()
: "Возвращает p с разрешенными символическими ссылками и результат нормализуется. Возвращает: Путь, состоящий из результата вызова функции canonical()
на пути, состоящем из ведущих элементов of p, которые существуют, если они есть, за которыми следуют элементы из p, которые не существуют, если они есть."
ИЗМЕНИТЬ 3:
Подробнее об этом относительно std::filesystem
.