Максимальная длина пути файла windows

Время на прочтение4 мин

Количество просмотров80K

Картинка с сайта: habr.com

Многим пользователям ПК под управлением ОС Windows, не говоря о разработчиках, знакомы проблемы при работе с длинными (более 260 символов, MAX_PATH) путями файлов или каталогов.

В данной статье рассматриваются способы избавления от этого пережитка при разработке приложений на различных платформах (WinApi, .Net Framework, .Net Core) и активации нативной поддержки длинных путей в Windows 10 (Anniversary Update).

Приложения Win API

В приложениях, которые используют Win API для работы с файлами, рецепт избавления от ограничения MAX_PATH был известен с незапамятных времён – необходимо было использовать Unicode версию функции с окончанием «W» для работы с директорией или файлом и начинать путь с префикса \\?\. Это давало возможность использовать пути длинной до 32767 символов.

В Windows 10 (1607) поведение функций для работы с файлами изменилось: появилась возможность отключить проверку ограничений MAX_PATH на уровне системы.

Это избавляет от необходимости использовать префикса \\?\ и потенциально даёт шанс приложениям, работающим напрямую или косвенно через Win API, получить поддержку длинных путей без необходимости их пересборки. Как активировать эту возможность описано в конце статьи.

.Net Framework

Хотя .Net Framework и использует Win API для работы с файлами — предыдущее изменение не принесло бы результата, т.к. в код BCL встроены предварительные проверки на допустимость длинны имён каталогов и файлов, и до вызова функций Win API дело даже не доходило, выдавая известное исключение. По многочисленным просьбам сообщества (более 4500 на UserVoice) в версии 4.6.2 из кода BCL вырезали проверки ограничения длинны пути, отдав это на откуп операционной и файловой системам!

Вот что это даёт:

• При использовании префикса “\\?\” мы можем работать с длинными путями как в Win API,

  Directory.CreateDirectory("\\\\?\\" + long_dir_name);

• Если активировать нативную поддержку длинных имен файлов Windows 10 (1607), то даже не потребуется использовать префикс!

Как включить:

• Использовать .Net Framework 4.6.2 как цель при сборке приложения.
• Использовать конфигурационный файл, например, если приложение уже было собрано под .Net 4.0:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
    </startup>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false" />
  </runtime>
</configuration>

.Net Core

Тут поддержку длинных путей анонсировали ещё в ноябре 2015 года. Видимо сказалось Open Source природа проекта и отсутствие строгой необходимости обеспечения обратной совместимости.

Как включить:
Всё работает из коробки. В отличие от реализации в .Net Framework – тут нет необходимости в добавлении префикса “\\?\” – он добавляется автоматически при необходимости.

Вот тут можно посмотреть пример.

Как включить поддержку длинных путей в Windows 10 (1607)

Эта возможность по умолчанию отключена. Это объясняется тем, что данная функция является экспериментальной, и имеется необходимость дорабатывать различные подсистемы и приложения для полной поддержки.

Включить встроенную поддержку длинных путей можно создав или изменив следующий параметр системного реестра: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem Параметр LongPathsEnabled (Тип: REG_DWORD) 1 – соответствует значению включено.

Картинка с сайта: habr.com

Или через групповые политики (Win+R\gpedit.msc) Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths.Оно же в локализованном варианте: Конфигурация компьютера > Административные шаблоны > Система > Файловая система > Включить длинные пути Win32.

Картинка с сайта: habr.com

Далее источники расходятся во мнении относительно манифеста (или я неправильно понял, но на данный момент проверить не имею возможности). Например, в документации MSDN написано, что манифест можно использовать в качестве альтернативного способа активации поддержки длинных путей в отдельных приложениях, а в блоге MSDN указано, что это является вторым обязательным шагом после активации в политиках.
Но они сходятся в формате задания данной опции:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

С CMD, к сожалению, это не сработает, на данный момент, из-за особенностей работы с путями, а в PowerShell должно всё заработать.

P.S.

На этом мой небольшой пятничный пост заканчивается, оставив за рамками вопросы полноты реализации поддержки длинных путей в Windows 10 (1607), или работоспособность при использовании различных комбинаций редакций Windows, файловых систем и API. По мере поступления новых фактов и результатов экспериментов пост будет обновляться.

Спасибо за внимание!

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку

Практически каждый пользователь Windows рано или поздно сталкивается с ошибкой «слишком длинный путь» (path too long). Ошибка эта возникает при работе с файлами или папками, у которых полный путь превышает значение в 260 символов.

Напомню, что полный путь включает в себя букву диска, двоеточие, обратный слэш, имена компонентов (файл, директория) разделенные слешем и завершающий пустой символ (NUL). Выглядит полный путь примерно так:

C:\directory\subdirectory\filename

Соответственно, если сумма всех компонентов пути больше 260 символов, то путь считается слишком длинным. Большинство приложений Windows не умеют работать с такими путями и при обращении к файлу\папке выдадут примерно такое сообщение:

Картинка с сайта: blog.evgenmed.com

Что интересно, значение в 260 символов обусловлено значением MAX_PATH Win32 API. У файловой системы NTFS максимальная длина пути «немного» больше и составляет  32767 символов. Для обхода ограничений Win32 API некоторые приложения используют формат UNC, указывая абсолютный путь с префиксом \\?\, например так:

\\?\C:\directory\subdirectory\filename

В Windows 10 (начиная с версии 1607) появилась возможность отключить проверку MAX_PATH и использовать длинные пути без префикса \\?\ . Сделать это можно двумя способами — с помощью групповых политик или путем редактирования реестра. Подробнее см. в статье.

А теперь огромная ложка дёгтя!

Проводника Windows всё вышеописанное не касается! 😡 На дворе конец июля 2018, у меня установлена 64-битная Windows 10 Корпоративная 2016 с долгосрочным обслуживанием версии 10.0.14393 Сборка 14393. Проводник Windows как ругался на длинные пути, так и продолжает ругаться, несмотря на применение всех рекомендаций, описанных выше. Это бред и позор индийских разработчиков или каких там еще, которые работают на Microsoft.

Приходиться пользоваться обходным решением — бесплатной утилитой стороннего разработчика Long Path Fixer. Обзор этой утилиты можно прочитать здесь.

POCO, ACE, Loki и другие продвинутые C++ библиотеки

NullReferenced 13.05.2025

В C++ разработки существует такое обилие библиотек, что порой кажется, будто ты заблудился в дремучем лесу. И среди этого многообразия POCO (Portable Components) – как маяк для тех, кто ищет. . .

Паттерны проектирования GoF на C#

UnmanagedCoder 13.05.2025

Вы наверняка сталкивались с ситуациями, когда код разрастается до неприличных размеров, а его поддержка становится настоящим испытанием. Именно в такие моменты на помощь приходят паттерны Gang of. . .

Создаем CLI приложение на Python с Prompt Toolkit

py-thonny 13.05.2025

Современные командные интерфейсы давно перестали быть черно-белыми текстовыми программами, которые многие помнят по старым операционным системам. CLI сегодня – это мощные, интуитивные и даже. . .

Конвейеры ETL с Apache Airflow и Python

AI_Generated 13.05.2025

ETL-конвейеры – это набор процессов, отвечающих за извлечение данных из различных источников (Extract), их преобразование в нужный формат (Transform) и загрузку в целевое хранилище (Load). . . .

Выполнение асинхронных задач в Python с asyncio

py-thonny 12.05.2025

Современный мир программирования похож на оживлённый мегаполис – тысячи процессов одновременно требуют внимания, ресурсов и времени. В этих джунглях операций возникают ситуации, когда программа. . .

Работа с gRPC сервисами на C#

UnmanagedCoder 12.05.2025

gRPC (Google Remote Procedure Call) — открытый высокопроизводительный RPC-фреймворк, изначально разработанный компанией Google. Он отличается от традиционых REST-сервисов как минимум тем, что. . .

CQRS (Command Query Responsibility Segregation) на Java

Javaican 12.05.2025

CQRS — Command Query Responsibility Segregation, или разделение ответственности команд и запросов. Суть этого архитектурного паттерна проста: операции чтения данных (запросы) отделяются от операций. . .

Шаблоны и приёмы реализации DDD на C#

stackOverflow 12.05.2025

Когда я впервые погрузился в мир Domain-Driven Design, мне показалось, что это очередная модная методология, которая скоро канет в лету. Однако годы практики убедили меня в обратном. DDD — не просто. . .

Исследование рантаймов контейнеров Docker, containerd и rkt

Mr. Docker 11.05.2025

Когда мы говорим о контейнерных рантаймах, мы обсуждаем программные компоненты, отвечающие за исполнение контейнеризованных приложений. Это тот слой, который берет образ контейнера и превращает его в. . .

Micronaut и GraalVM — будущее микросервисов на Java?

Javaican 11.05.2025

Облачные вычисления безжалостно обнажили ахиллесову пяту Java — прожорливость к ресурсам и медлительный старт приложений. Традиционные фреймворки, годами радовавшие корпоративных разработчиков своей. . .

Как известно, длина имени файла в Windows ограничена 256 символами. В программировании используется константа MAX_PATH, которая равна 260. Судя по названию, она означает максимальную длину пути в Windows, которая складывается из максимальной длины имени каталога 255 символов + слэш на конце + завершающий нулевой символ, и из символов, означающих букву диска в количестве трёх штук (например, «C:\»). Всё это вместе даёт длину пути 260. На самом деле это ограничение в 260 символов есть только в Windows API. В самой файловой системе (FAT32 или NTFS) максимальная длина имени файла ограничена 255 символами, но максимальная длина пути может быть гораздо больше, чем поддерживает WinAPI. Поэтому, ограничение на длину пути может быть преодолено. Посмотрим, что об этом сказано в документации. 

The wide (Unicode) versions of the CreateDirectory, FindFirstFile, GetFileAttributes, and SetFileAttributes functions permit paths that exceed the MAX_PATH length if the path has the «\\?\» or «\\?\UNC\» prefix. These prefixes direct the functions to turn off path parsing. Use the «\\?\» prefix with paths for local storage devices and the «\\?\UNC\» prefix with paths having the Universal Naming Convention format. 

Unicode-версии функций CreateDirectory, FindFirstFile, GetFileAttributes, и SetFileAttributes позволяют использовать пути, превышающие длину MAX_PATH, если путь имеет префикс «\\?\» or «\\?\UNC\». Эти префиксы указывают функции на необходимость отключения проверки пути. Используйте «\\?\» префикс для путей на локальных носителях, а «\\?\UNC\» для путей, которые имеют UNC-формат. 

То есть, ничто не мешает нам, используя префикс «\\?\», создать путь с длиной большей, чем 260 символов. 

Я написал небольшую программу, которая создаёт на диске С: много вложенных друг в друга каталогов «next». Программа прекращает создавать каталоги, если функция CreateDirectory вернула FALSE (достигнут предел длины пути в используемой файловой системе), или переполнился буфер, использованный для хранения пути (по-умолчанию — 32 кб). 

Я протестировал программу на Windows XP Pro SP2 Rus, первый раз на диске C:\, где у меня используется NTFS, а второй раз на дискете, где FAT16. На FAT32 разделах не проверял, так как у меня на компьютере таких нет. На дискете удалось создать путь длиной примерно 32000 символов. При этом таблица размещения файлов так разрослась, что заняла 264 килобайта! При этом никаких больше файлов на дискете не было — только вложенные пустые каталоги. 

Не знаю, связано ли это как-то с моими экспериментами над файловой системой, но после создания длинного пути на диске C:\, мой компьютер сам собой два раза перезагрузился. Потом я из защищённого режима удалил все эти вложенные каталоги, и комп больше себя так не ведёт. Возможно, это никак не связано с превышением максимальной длины пути, возможно это просто глюки железа моего не совсем нового компьютера.