Подтвердить что ты не робот

Ограничение MAX_PATH в Boost.Filesystem

Я хочу использовать библиотеку Boost.Filesystem для управления путями, файлами и каталогами. Мой вопрос: пути длиннее MAX_PATH?

Я знаю, что в Win32API у нас есть обходной путь "\\? \", но он не поддерживается базовыми функциями, такими как PathAppend и PathCombine.

Итак, я ищу любую полезную информацию о MAX_PATH и Boost.FS.

Спасибо

UPD: Я забочусь обо всех действиях, таких как добавление путей, объединение путей и т.д. (у меня есть эти функции в Win32API, но они не работают с путями длиннее MAX_PATH) Например, CreateFileW и DeleteFileW поддерживают пути дольше MAX_PATH. May Boost.FS будет заменой для служебных функций Win32API, таких как найденные в shlwapi и shell32, которые часто не поддерживают длинные пути

4b9b3361

ОТВЕТЫ

Ответ 1

На самом деле Windows поддерживает пути любой длины, и любой путь может быть преобразован в строку в окнах. В этом случае требуется добавить \\?\, но это часть операции "сделать строку из заданного пути".

AFAIK, Boost:: FileSystem делает это неправильно в окнах.

Я не знаю, планируется ли исправление. См. о том, как это сделать.

Ответ 2

Вы можете манипулировать любой длиной строки пути файловой системы с помощью Boost.Filesystem или без нее.

MAX_PATH - это ограничения API файлов Windows. То есть вы не можете передать слишком длинную строку пути в Windows API.

Например, функция удаления Boost.Files будет сбой длиннее пути длины MAX_PATH. Вы хотите, чтобы Boost.Filesystem выполняла что-то вроде изменения текущего каталога и использовала относительный путь для предотвращения ограничения MAX_PATH? Я не думаю, что это возможно.

EDITED

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

Я не знаю, поддерживает ли Boost.Filesystem путь Unicode Win32, но вы можете преобразовать конечный путь ANSI в путь Unicode до вызова API-интерфейсов Win32.