Включить длинные пути 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 символов.

Напомню, что полный путь включает в себя букву диска, двоеточие, обратный слэш, имена компонентов (файл, директория) разделенные слешем и завершающий пустой символ (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 проводник все так же не поддерживает длинные пути файлов. Вот так 🙁

Modify applicable registry settings as listed in the below answers to potentially help resolve.

Know your Build Version

You can run WINVER to see what build your Windows 10 is but from what I gather with a little reading, the enabling of NTFS long paths is available as of Build 14352 and later, so check to see if your build release is older than that for an explanation why it’s not an option from Group Policy otherwise.

Update — Newer Version Builds

^{WARNING: Before working in the Windows Registry, it is always a good idea to back it up first, so that you have the option of restoration, should something go wrong. This article shows the different ways to back up and restore the Windows Registry or its Hives.}

It seems that the registry locations with some of the latest Windows 10 Anniversary updates have changed a bit to enable the Long Paths to help overcome the Windows API file paths and names that exceed a 255-260 character limit for such programs in Windows that can utilize this once enabled.

Registry Import Enabling Long Paths

Windows Registry Editor Version 5.00
   
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

Optional Registry Value

The below registry key value changed when the option was made with the Local Group Policy editor to enable Enable Win32 long paths but the <SID> portions will likely be different per account defined with a profile, etc. on the local Windows 10 machine s plug those values in accordingly per what you see when you look there with regedit.

Windows Registry Editor Version 5.00

[HKEY_USERS\S-1-5-21-[<SID>-<SID>-<SID>]-1001\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects\{B0D05113-7B6B-4D69-81E2-8E8836775C9C}Machine\System\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

^{NOTE: Once you have these imported, you’ll want to reboot to ensure the changes become effective just in case. It has been reported that these settings and even Group Policy settings that change these values and others do NOT always work with File Explorer or all Windows programs as those have to be coded to handle this explicitly from what I gather so this is not a 100% for sure will fix all issues but this is Microsoft’s step forward moving to resolve this limitation.}

Previous Version Builds

^{Warning: These below settings may not work for all builds of Windows 10 so you will need to backup, check, test, etc. but see the options above if you’ve not already.}

Using the Registry instead at HKLM Level

1. Hit the Windows key, type regedit and press Enter

2. Go to the following Registry key:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Policies

3. On the right side, create a new 32-bit DWORD value named LongPathsEnabled. Set its value data to 1.

1. Restart Windows 10

_source

Using the Registry instead at HKCU Level

1. Hit the Windows key, type regedit and press Enter.
2. Navigate to: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group
   Policy Objects{48981759-12F2-42A6-A048-028B3973495F}
   Machine\System\CurrentControlSet\Policies
3. Select the LongPathsEnabled key, or create it as a DWORD (32-bit)
   value if it does not exist.
4. Set the value to 1 and close the Registry Editor.

_source