Почему в Windows существует ограничение длины пути в 260 символов?

Я сталкивался с этой проблемой несколько раз в неподходящие моменты:

• Попытка работать над проектами Java с открытым исходным кодом с глубокими путями
• Хранение глубоких вики-деревьев Fitnesse в системе контроля версий
• Ошибка при попытке использовать Bazaar для импорта моего дерева управления исходным кодом

Почему существует этот предел?

Почему это еще не было удалено?

Как вы справляетесь с ограничением пути? И нет, переход на Linux или Mac OS X не является правильным ответом на этот вопрос;)

Цитирование этой статьи https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Ограничение максимальной длины пути

В Windows API (с некоторыми исключениями, обсуждаемыми в следующих параграфах) максимальная длина пути равна MAX_PATH , которая определяется как 260 символов. Локальный путь структурируется в следующем порядке: буква диска, двоеточие, обратная косая черта, компоненты имен, разделенные обратной косой чертой, и завершающий нулевой символ. Например, максимальный путь на диске D равен «D: \ some 256-символьная строка пути <NUL>», где «<NUL>» представляет невидимый завершающий нулевой символ для текущей системной кодовой страницы. (Символы <> используются здесь для наглядности и не могут быть частью допустимой строки пути.)

Теперь мы видим, что это 1 + 2 + 256 + 1 или [диск] [: \] [путь] [ноль] = 260. Можно предположить, что 256 - это разумная фиксированная длина строки из дней DOS. Возвращаясь к API DOS, мы понимаем, что система отслеживает текущий путь на диск, и у нас есть 26 (32 с символами) максимум дисков (и текущих каталогов).

INT 0x21 AH = 0x47 говорит: «Эта функция возвращает описание пути без буквы диска и начальной обратной косой черты». Итак, мы видим, что система хранит CWD в виде пары (диск, путь), и вы запрашиваете путь, указывая диск (1 = A, 2 = B,…), если вы задаете 0, то она принимает путь для привод возвращается INT 0x21 AH = 0x15 AL = 0x19. Итак, теперь мы знаем, почему это 260, а не 256, потому что эти 4 байта не хранятся в строке пути.

Почему строка пути 256 байт, потому что 640 КБ достаточно ОЗУ.

Это не совсем так, поскольку файловая система NTFS поддерживает пути до 32 тыс. Символов. Вы можете использовать API-интерфейс win32 и \\?\префикс " ", чтобы использовать путь длиной более 260 символов.

Подробное объяснение длинного пути из блога команды .Net BCL .
Небольшая выдержка подчеркивает проблему с длинными путями

Еще одна проблема - непоследовательное поведение, которое может возникнуть в результате предоставления поддержки длинного пути. Длинные пути с \\?\префиксом могут использоваться в большинстве файловых API Windows, но не во всех Windows API. Например, LoadLibrary, который отображает модуль на адрес вызывающего процесса, завершается ошибкой, если имя файла длиннее, чем MAX_PATH. Таким образом, это означает, что MoveFile позволит вам переместить библиотеку DLL в такое место, где ее путь будет длиннее 260 символов, но при попытке загрузить библиотеку DLL произойдет сбой. Есть аналогичные примеры в Windows API; Существуют некоторые обходные пути, но они применяются в каждом конкретном случае.

Вопрос в том, почему ограничение все еще существует. Конечно, современные Windows могут увеличить сторону, MAX_PATHчтобы позволить более длинные пути. Почему ограничение не было снято?

• Причина, по которой его нельзя удалить, заключается в том, что Windows пообещала, что это никогда не изменится.

Благодаря контракту API, Windows гарантировала всем приложениям, что стандартные файловые API никогда не будут возвращать путь длиннее 260символов.

Рассмотрим следующий правильный код:

WIN32_FIND_DATA findData;

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

Windows гарантировала моей программе, что она заполнит мою WIN32_FIND_DATAструктуру:

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

Мое приложение не объявляло значение константы MAX_PATH, а Windows API. Мое приложение использовало это определенное значение.

Моя структура правильно определена, и только выделяет 592всего байтов. Это означает, что я могу получить только имя файла, которое меньше 260символов. Windows пообещала мне, что если я напишу свое приложение правильно, оно продолжит работать в будущем.

Если бы Windows разрешала имена файлов длиннее 260символов, то мое существующее приложение (которое правильно использовало правильный API) не получилось бы.

Любой, кто призывает Microsoft изменить MAX_PATHконстанту, сначала должен убедиться, что ни одно из существующих приложений не выходит из строя. Например, я все еще владею и использую приложение Windows, которое было написано для работы в Windows 3.11. Он по-прежнему работает на 64-битной Windows 10. Это то, что дает вам обратная совместимость.

Microsoft сделал создать способ использовать полные имена путей 32768; но они должны были создать новый контракт API для этого. Во-первых, вы должны использовать Shell API для перечисления файлов (поскольку не все файлы существуют на жестком диске или в сетевой папке).

Но они также должны не нарушать существующие пользовательские приложения. Подавляющее большинство приложений не используют API оболочки для работы с файлами. Каждый просто звонит FindFirstFile/ FindNextFileи называет это днем.

В Windows 10. вы можете снять ограничение , изменив раздел реестра.

Подсказка Начиная с Windows 10 версии 1607 ограничения MAX_PATH были удалены из общих функций файлов и каталогов Win32. Тем не менее, вы должны подписаться на новое поведение.

Раздел реестра позволяет вам включить или отключить новый длинный путь поведения. Чтобы включить поведение длинного пути, задайте в разделе реестра значение HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled(Тип:) REG_DWORD. Значение ключа будет кэшироваться системой (для каждого процесса) после первого вызова уязвимой функции файла или каталога Win32 (список следует). Раздел реестра не будет перезагружен в течение всего жизненного цикла процесса. Чтобы все приложения в системе могли распознать значение ключа, может потребоваться перезагрузка, поскольку некоторые процессы могли быть запущены до того, как ключ был установлен. Раздел реестра также можно контролировать с помощью групповой политики на Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. Вы также можете включить новое поведение длинного пути для приложения через манифест:

<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>

Вы можете смонтировать папку как диск. Из командной строки, если у вас есть путь, C:\path\to\long\folderвы можете сопоставить его с буквой диска, X:используя:

subst x: \path\to\long\folder

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

Например:

1. создать C:\pкаталог для хранения коротких ссылок на длинные пути
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. добавить C:\p\fooк вашему пути вместо длинного пути

Вы можете включить длинные имена путей, используя PowerShell:

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

Другая версия заключается в использовании групповой политики в Computer Configuration/ Administrative Templates/ System/ Filesystem:

Что касается того, почему это все еще существует - MS не считает это приоритетом и ценит обратную совместимость по сравнению с продвижением своих ОС (по крайней мере, в этом случае).

Обходной путь, который я использую, состоит в том, чтобы использовать «короткие имена» для каталогов в пути, вместо их стандартных, удобочитаемых версий. Так, например, для C:\Program Files\я бы использовал C:\PROGRA~1\ Вы можете найти эквиваленты короткого имени, используя dir /x.

Что касается того, как справиться с ограничением размера пути в Windows - использование 7zip для упаковки (и распаковки) файлов, чувствительных к длине пути, кажется приемлемым обходным путем. Я использовал его для переноса нескольких инсталляций IDE (эти пути к подключаемым модулям Eclipse, yikes!) И груды автоматически сгенерированной документации, и до сих пор не было ни одной проблемы.

Не совсем уверен, как он преодолевает ограничение в 260 символов, установленное Windows (из технической точки зрения), но эй, это работает!

Более подробная информация на их странице SourceForge здесь :

«NTFS может поддерживать имена путей длиной до 32 000 символов».

7-zip также поддерживают такие длинные имена.

Но это отключено в коде SFX. Некоторым пользователям не нравятся длинные пути, так как они не понимают, как с ними работать. Вот почему я отключил его в коде SFX.

и примечания к выпуску :

9.32 альфа 2013-12-01

• Улучшена поддержка имен файлов длиннее 260 символов.

4.44 бета 2007-01-20

• 7-Zip теперь поддерживает имена файлов длиной более 260 символов.

ВАЖНОЕ ПРИМЕЧАНИЕ. Чтобы это работало правильно, вам нужно указать путь к месту назначения в диалоговом окне «Извлечь» из 7zip , а не перетаскивать файлы в нужную папку. В противном случае папка «Temp» будет использоваться в качестве промежуточного кэша, и вы попадете в то же ограничение в 260 символов, как только Windows Explorer начнет перемещать файлы в их «окончательное место покоя». Смотрите ответы на этот вопрос для получения дополнительной информации.

Это так, и по какой-то причине это значение по умолчанию, но вы можете легко переопределить его следующим ключом реестра:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

См .: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/.

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

Например, он позволяет копировать, перемещать или переименовывать файлы, что даже Windows Explorer не может. Или, конечно, иметь дело с содержимым таких как md5sum, grep, gzip и т. Д.

Также для программ, которые вы кодируете, вы можете связать их с Cygwin DLL, и это позволит им использовать длинные пути (хотя я не проверял это, хотя)