Windows 10 максимальная длина пути к файлу

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

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

Многим пользователям ПК под управлением ОС 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 – соответствует значению включено.

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

Далее источники расходятся во мнении относительно манифеста (или я неправильно понял, но на данный момент проверить не имею возможности). Например, в документации 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 символов. Многие приложения, в том числе проводник Windows, неправильно работают с такими длинными именами файлов, оказываясь их открывать, перемещать и удалять. Это ограничение не файловой системы NTFS, а библиотеки Win32 API (подробнее о проблеме и обходных способах ее решения рассказано здесь).

В новой сборке Windows 10 Insider Preview Build 14352 доступной участникам программы Windows Insider, появилась новая возможность отключить ограничение на максимальную длину пути.

Отключить ограничение MAX_PATH можно двумя способами: с помощью редактора групповых политик или через реестр. Рассмотрим оба:

1. Запустите консоль редактора локальной групповой политики, нажав Win+R и выполнив команду gpedit.msc
2. Перейдите в раздел редактора Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Filesystem -> NTFS (Конфигурация компьютера -> Административные шаблоны -> Система -> Файловая система -> NTFS)
3. Откройте политику Enable NTFS long paths
4. Включите политику, переведя ее в состояние Enabled
5. Сохраните изменения

При использовании домашней версии Windows 10, в которой отсутствует редактор GPO, это же изменение можно внедрить с помощью редактора реестра.

1. Запустите редактор реестра regedit.exe
2. Перейдите в ветку HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects\{48981759-12F2-42A6-A048-028B3973495F}Machine\System\CurrentControlSet\Policies
3. Создайте в данной ветке новый параметр типа Dword (32-bit) Value с именем LongPathsEnabled
4. Чтобы отключить ограничение MAX_PATH, измените значение ключа на 1

Также вы можете включить эту функцию одной командой PowerShell:
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled -Value 1

Для вступления изменений в силу в обоих случаях требуется перезагрузка компьютера. После перезагрузки пользователи и программы смогут без ограничений работать с файлами, длина пути к которым превышает 260 символов. Теперь на файлы будет действовать только ограничение файловой системы NTFS – 32767 символов .

Этот функционал доступен всем пользователям Windows 10, начиная с Anniversary Update (1607), и в Windows Server 2016.

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

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

C:\directory\subdirectory\filename<NUL>

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

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

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

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

Групповые политики

Первым делом  открываем редактор локальных групповых политик, для чего жмем клавиши Win+R и выполняем команду gpedit.msc.

Нужная нам политика находится в разделе Конфигурация компьютера\Административные шаблоны\Система\Файловая система (Computer configuration\Administrative templates\System\Filesystem) и называется Включить длинные пути Win32 (Enable Win32 long paths).

Для активации поддержки длинных путей надо перевести политику в состояние «Включено».

Реестр

Для включения поддержки длинных путей через реестр необходимо найти в разделе HKLM\System\CurrentControlSet\Control\FileSystem параметр с именем LongPathEnabled и задать его значение равным 1.

Эту операцию можно произвести с помощью PowerShell, командой:

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled -Value 1

В обоих случаях потребуется перезагрузить компьютер. После перезагрузки изменения вступят в силу и для путей будет действовать только ограничение файловой системы NTFS (32767 символа), превысить которое вам навряд ли удастся. Однако это вовсе не значит, что можно расслабится. В некоторых приложениях проверка MAX_PATH заложена в коде,  поэтому  по возможности лучше не превышать это ограничение.

Дополнение

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

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

А теперь о грустном. Как внезапно оказалось, в проводнике Windows поддержка длинных путей не реализована!!! Один из разработчиков Microsoft по этому поводу сказал примерно следующее:

″Эта функция не готова для включения в Windows Explorer. Вам нужно подождать, пока Microsoft не включит ее в Explorer, или использовать сторонний инструмент управления файлами, который совместим с длинными путями. ″

Это было сказано еще в 2016 году. Но, судя по всему, разработчики на данную проблему просто забили. На данный момент в версии 1903 проводник все так же не поддерживает длинные пути файлов. Вот так 🙁

The question is why does the limitation still exist. Surely modern Windows can increase the side of MAX_PATH to allow longer paths. Why has the limitation not been removed?

• The reason it cannot be removed is that Windows promised it would never change.

Through API contract, Windows has guaranteed all applications that the standard file APIs will never return a path longer than 260 characters.

Consider the following correct code:

WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);

Windows guaranteed my program that it would populate my WIN32_FIND_DATA structure:

WIN32_FIND_DATA {
   DWORD    dwFileAttributes;
   FILETIME ftCreationTime;
   FILETIME ftLastAccessTime;
   FILETIME ftLastWriteTime;
   //...
   TCHAR    cFileName[MAX_PATH];
   //..
}

My application didn’t declare the value of the constant MAX_PATH, the Windows API did. My application used that defined value.

My structure is correctly defined, and only allocates 592 bytes total. That means that i am only able to receive a filename that is less than 260 characters. Windows promised me that if i wrote my application correctly, my application would continue to work in the future.

If Windows were to allow filenames longer than 260 characters then my existing application (which used the correct API correctly) would fail.

For anyone calling for Microsoft to change the MAX_PATH constant, they first need to ensure that no existing application fails. For example, i still own and use a Windows application that was written to run on Windows 3.11. It still runs on 64-bit Windows 10. That is what backwards compatibility gets you.

Microsoft did create a way to use the full 32,768 path names; but they had to create a new API contract to do it. For one, you should use the Shell API to enumerate files (as not all files exist on a hard drive or network share).

But they also have to not break existing user applications. The vast majority of applications do not use the shell api for file work. Everyone just calls FindFirstFile/FindNextFile and calls it a day.