В Windows есть известный анахронизм, ограничивающий максимальную длину пути к файлу или папке 260 символами. Проводник Windows (File Explorer) и многие приложения не умеют с такими длинными именами файлов. При попытке создать, сохранить, скопировать или переместить папки/файлы с путями, превышающими лимит, пользователь может получать ошибки вида «
path too long
«, «
слишком длинный целевой путь
«, «
указано неправильно или слишком длинное имя файла
» и т.п.
Данное ограничение накладывается не файловой системой NTFS, а Win32 API, в котором определяется максимальная длина пути (MAX_PATH) 260 символов. Это включает в себя букву диска (например,
E:\
, занимающую 3 символа), путь к папке, имя файла и невидимый завершающий
NULL
-символ (1 символ). Таким образом максимальное имя файла/папки может быть 256 символов (подробнее о проблеме и обходных способах ее решения рассказано здесь).
Начиная с Windows 10 (1607) и Windows Server 2016, доступен отдельный параметр групповых политик, позволяющий включить поддержку длинных путей в Windows. По умолчанию этот параметр отключен. Чтобы включить его:
- Откройте редактор локальной GPO (
gpedit.msc
) - Перейдите в ветку Computer Configuration -> Administrative Templates -> System -> Filesystem (Конфигурация компьютера -> Административные шаблоны -> Система -> Файловая система)
- Включите параметр Enable Win32 long paths (Включить длинные пути Win32)
- Чтобы применить эту настройку, нужно перезакрузить компьютер.
Либо можно включить параметр, обеспечивающий поддержку длинных путей напрямую через реестр:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled /t REG_DWORD /d 1 /f
Итак, вы включили поддержку длинных путей в Windows, однако это не означает, что теперь все программы будут корректно работать с путями, превышающими лимит.
Дело в том, что приложение должно быть специально разработанным для работы с длинными путями и в его манифесте должна быть включена опция longPathAware. Проверить поддерживает ли конкретное приложение работу с длинными путями можно по его манифесту. Иногда это бывает отдельный XML файл, хранящийся в каталоге приложения, или (чаще всего) манифест зашит в исполняемый EXE файл.
<ws2:longPathAware>true</ws2:longPathAware>
означает, что Acrobat Reader поддерживает длинные пути и будет корректно работать с такими файлами после включения политики LongPathsEnabled.Старые или специализированные программы могут по-прежнему конфликтовать с длинными путями. Тот же редактор Microsoft Word и другие программы пакета Office не поддерживают длинные пути. Более того, проводник Windows (File Explorer) также до сих пор (!!!) не поддерживает работу с объектами путь к которым превышает значение MAX_PATH Win32 API.
Для обхода ограничения Win32 API многие приложения сразу разрабатываются для использования абсолютный путь к файлу, на который не действует ограничение MAX_PATH. В этом UNC формате путь к файлу будет выглядеть так:
\\?\C:\SomeLongPath\LongNameFile.txt
Если ваше приложение не поддерживает режим longPathAware, можно использовать формат пути с префиксом
\\?\
для доступа к файлам. Это позволит обойти ограничение MAX_PATH.
Естественно, использовать глубокую вложенность папок и/или очень длинные имена файлов – это плохая практика, с которой я в последнее время встречаюсь крайне редко. Такой проблемой обычно грешат пользователи файловых серверов, создавая сложные иерархические структуры каталогов. Как вариант, можно отслеживать максимальную длину пути на файловые серверах с помощью скриптов и бороться с этой напастью организационно.
Подскажите, а можно ли такое ограничение и в windows 7 ultimate x64 снять тоже и как это сделать?
Пока это работает только в Windows 10 Build 14352, для Windows 7 пока патча нет. И не факт, что появится, ведь вам же пока предлагают «совершенно бесплатно обновится до Windows 10» 🙂
Толку от этого патча нуль, индуский софт, почти везде проверяет длину пути в 255 символов. А если софт китайский, то он еще и отличный от китайского/английского не умеет. Профитнее 8dot3 отключить без чистки, потому, что рудименты винды используют короткие имена.
You can try Long Path Tool, it will definitely help you.
Try long path tool is very useful for situations where it shows cannot delete file or folder, cannot read from source file or disk. It works seamlessly to give effective result.
Я в место «приурочено к годовщине выхода Windows 10» прочитал «приурочено к ГО**ЩЕ выхода Windows 10». Видимо глубоко засела у меня ассоциация windows 10 с го**ом)))
Ассоциации обычно соответствуют уровню развития или зависят от каким-то скрытых комплексов 😉
Всего лишь игра слов, таким образом я высказал свое впечатление об этой системе. А вот у умников вроде тебя, которые оставляют не в тему бессмысленные комментарии, действительно имеются скрытые комплексы и соответствующий уровень развития.
Совершенно верно ~ от уровня развитости!
Виндоус 10 для дебилов, потому она не
развитая. Следовательно пользователь
Сергей так прочитал и cовершенно прав,,,
Нету такого не в групповой политике ни в реестре. Версия 1703 (Сборка ОС 15063.726)
Как вы думаете, что означал высокотехнологичный термин «создайте» в 3-м пункте части про редактор реестра? 🙂
Добавьте в статью команду power shell: Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled -Value 1
Реально удобней, чем regedit и искать, где там этот пареметр.
Согласен, обновил статью.
Зачем искать, скопировал путь из статьи да вбил его в адресное поле.
Не работает на сервере 2016.
ПОлитика точно отрабатывает, ключ в реестре поменялся на 1.
Но длинные имена не работают, куда смотреть?
Вы на WS 2016 обновления ставите?Возможно начиная с какого-то билда поддержка пошла…
UPD. Вот, нашел
starting from build 1607, Windows Server 2016 now supports longer paths up to 1024 characters with the proper registry configuration
Только что поставил эту самую Windows 10, качал с сайта, потому все обновления должны были бы уже быть. Так вот, ПАРАМЕТРА С ОПИСЫВАЕМЫМ ПУТЕМ ТАМ НЕТ! Остальные 5 параметров, как на скриншоте, есть, а именно этого — НЕТ! Полез в реестр, там тоже таких ключей нет. Ну, хрен с ними, насоздавал я их сам. Но результат нулевой, и после перезагрузки нулевой.
Но, если в групповой политике выйти на уровень выше, т.е. не папка NTFS, а папка «Файловая система», тот там будет некий ключ с названием «Включить длинные пути Win32». Я, конечно, мальчик уже большой, и в сказки давно не верю, что microsoft захочет сделать нам что-то хорошее, потому не сомневаюсь, что его включение тоже вряд ли что-то исправит. Но на всякий случай включил. А вдруг да и…
Какай версия (билд Windows 10) и редакция (Home/pro и т.д.)? — команда
winver
На Windows 10 2004 описанный метод не работате
На Windows 10 20H2 Pro в реестре эти параметры хранятся в 2 местах:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
«LongPathsEnabled»=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FileSystem]
«LongPathsEnabled»=dword:00000001
ControlSet001 — Это резервная копия ветки реестра CurrentControlSet.
Для старта последней удачной конфигурации Windows.
У меня всё выставлено как в статье. Но глубоко вложенную папку копировать Проводник так и не даёт. После перезагрузки ПК даже. Win 10. И чё делать.
В пункте 2 путь :
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects\{48981759-12F2-42A6-A048-028B3973495F}Machine\System\CurrentControlSet\Policies
Такого пути нет.
В пункте 3 на картинке путь:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies
Поправьте немного.
Ставьте Total Comander или FAR, не мучайте себя… не работает эта фигня, что в статье описана. Win10 Корпоративная LTSC 1809 сборки.
Да все работает, просто встроенный проводник не умеет такое. Total Comander или FAR умеют такое даже без этой настройки, а каким-то программам все же нужна эта галочка.
Автор статьи, ты хоть сам проверяй все это! на скринах одно, в тексте другое. что за бред? чего голову морочите людям?
Рабочий метод: по этому пути HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem меняем параметр LongPathsEnabled с 0 на 1. если нет этого параметра, то создаем ручками . далее в командной строке вбиваем gpupdate /force и пользуемся без перезапуска компьютера
Теперь этот параметр в групповых политиках называется иначе — «Включить длинные пути Win32» и вынесен из папки «NTFS» в папку «Файловая система»
Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Filesystem
Конфигурация компьютера -> Административные шаблоны -> Система -> Файловая система
Спасибо тебе Дружище! ты сделал мне день.
Пришлось после многих лет после MacOs пользоваться Win11, попалась домашняя, куча проблем. тупо невозможно скоприровать каталоги — ошибка длины имени файла. Полдня убил чтоб найти твой коммент.
Не говоря уже о том что все эти bat файлы не запускаются, которыми якобы можно это исправить..
Не работает. Компы в домене, все Win10 22H2 чистая сборка с сайта майкрософт и файл-сервер Win 2019 на ReFS (сборка хз какая). Все обновления установлены.
В политиках в папке NTFS как на скриншоте данного пункта нет, есть на уровень выше, в директории «Файловая система» политика «Включить длинные пути Win32».
Включил.
gpupdate /force, перезагрузки и т.д. не помогло. В реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem параметр LongPathsEnabled был включен (видимо как раз этой политикой), и всё равно не работает ни-че-го (((
Ни с сервера, напрямую с диска, ни с рабочей станции по шаре, никак. Пропадает пункт «безопасность» в свойствах файла и путь в свойствах указан как \\?\UNC\ и т.д.
Файл можно вытащить на раб стол, сократить имя, и положить обратно — сразу всё ок.
Хотя не, чё-то заработало. Adobe Acrobat начал открывать файлы в таких папках. До этого писал ошибку доступа. Но Word 2021 всё равно не справляется, и вкладка «Безопасность» не появляется. Несмотря на это, спасибо большое за статью. Ждём нормального решения от майков.
260 символов пути, видимо, также, как и 640кб. ОЗУ должно было по плану точно хватить на все случаи жизни