Выбираем длинный путь (или прощай MAX_PATH)

[a553]

Windows Registry Editor Version 5.00

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



[pda0]

Круто, конечно. И настало счастье, всем, кроме тех 100500 программ, что уже скомпилированы с MAX_PATH = 260. :)

[pda0]

Нет, я подумал об этом, но вспомнил, что во все эти функции надо передавать размер буфера.

[orcy]

Если манифест обязателен, то с безопасностью все должно быть пучком

[pda0]

Это не остановит народ от того, чтобы включать в программы примеры 20-летней давности. Беды особой нет, но и профита не будет.

[fedorro]

А в чём, собственно, дыра? Если в приложении есть переполнение буфера при передаче длинного пути файла, то его можно использовать и без этого. Если оно срабатывает при попытке открытия реального файла с длинным путём, то такие файлы и пути и раньше можно было без проблем создать.

[none7]

Надо думать это изначально была наша большая ошибка. Все WinAPI умеют работать с \\?\ путями со времён Win2k. В очень старой документации по WinAPI прямо в описании CreateFile чётко сказано, что начиная с WinNT, Unicode пути с приставкой \\?\ могут быть длиной 32000 символов. Не заметить этого можно было лишь читая документацию по диагонали. MAX_PATH это только для ANSI и DOS совместимости. Скрин той справки: https://yadi.sk/i/rN65fYVLtxKrn

[pda0]

Это даже в статье есть. Тем не менее, значительное количество примеров в интернетах основано именно на MAX_PATH. В основном потому, что это или кочующие примеры времён Win9x или написаны на их основе. Но реальность такова, что именно этот код навставляло себе приличное количество разработчиков. Да, они ССЗБ. Тем не менее.

[paratrooper5730]

благими намерениями выстлана дорога в ад. Какую только полезную информацию пользователи не додумаются запихнуть в имена файлов и папок. В полном пути документа на файловой шаре может четыре раза содержаться имя компании, пару раз слово «NEW», и конечно, побольше плюсов, минусов, восклицательных знаков — как же без них.
Единственным аргументом против этого безумия до сих пор оставались технические ограничения винды.

[rrrav]

Если каша у людей в голове, то нет границ безумию. Погрузите их в эпоху ДОС (8+3 — романтика...) — все равно найдут способы превратить в ад структуру каталогов.
Если кто-то нарушает принятые в организации принципы именования папок и документов, подкиньте ему зацикленную символическую ссылку в качестве наказания.

[sergey-b]

Хочу по полемизировать с вашим комментарием, несмотря на то, что прошло уже 3 года.

Привычку запихивать в имена файлов и каталогов спецсимволы и ненужную информацию культивировал сам Микрософт. Для этого у него есть как минимум 2 папки с названиями Program Files и Program Files (x86), куда по умолчанию устанавливаются все программы.

[Arxitektor]

Натыкался всего несколько раз
1) при скачивании торнетов
2) при сохранении веб страниц
Может через пару лет проблему путей решат окончательно.

[Alex_ME]

Сталкивался этим при создании проекта ASP.NET Core — bower скачивает frontend-зависимости и пихает их в такое количество вложенных папок, что проводник Windows потом отказывается удалить папку с этим проектом.

Заголовок спойлера

\?\d:\Programming_WEB\xxxxxx\xxxxxx_old\xxxxxx\src\xxxxx\node_modules\grunt-contrib-less\node_modules\less\node_modules\request\node_modules\har-validator\node_modules\is-my-json-valid\node_modules\generate-object-property\node_modules\is_property...

[evnik]

Не вдавался в подробности, но проводник таки позволяет удалять такие папки. Ошибка возникает только если относительный путь превышает MAX_PATH. Т.е. можно зайти в предпоследнюю по вложенности папку и в ней все удалить, потом перейти выше и удалить еще… Если длина пути позволяет, можно даже с середины начинать.
Альтернативный способ — с помощью subst создать виртуальный диск, указывающий на папку, не лежащую в корне.

[vovanza]

кто работал с Autodesk Vault знает что это приложение создает рабочую папку на диске, вложенность структуры проектов может быть очень большая, но все упирается в ограничения файловой системы, при выдаче файла и превышении суммы папок и имен файлов, наступает кирдык, устраняемый только руками и переносом файлов вверх по структуре, может быть это будет в прошлом

[Andrey_Vladimirovich]

Надо же параметр ЛГП "Включить длинные пути Win32" заработал. Проверял несколько лет назад, проводник тупо его игнорировал.

[fedorro]

Можете рассказать подробнее? У меня он до сих пор его игнорирует.

[Andrey_Vladimirovich]

Я немного ошибся. Да, теперь проводник в состоянии создать длинный путь и с ним работать, но всё равно это как-то криво реализовано. Далее, примеры с запуском различных файлов расположенных в пути, длина которого превышает 300 символов, с помощью проводника в Win10 x64 Pro 20H2, сборка ОС 19042.1110. Например, если я запускаю файл ассоциированный с Блокнотом (или выбираю «Открыть с помощью»), то проблем нет, файл исправно открывается. А вот, если попытаться открыть PNG-файл в Paint, то ничего не происходит, никаких сообщений, просто игнорирование события. Самим Paint’ом можно войти в папку и выбрать файл, но открывать его он не будет, без каких либо сообщений. Похожая ситуация при попытке открыть HTML-файл в браузере Edge или FireFox. Но, оказалось, что, если самим FireFox зайти в папку то файл исправно открывается (как то же самое сделать в Edge я так и не понял). Notepad++ отказывается работать с таким путём. Им самим можно туда зайти и выбрать файл, но он его не откроет без каких либо сообщений. Если попытаться открыть файл ассоциированный с LibreOffice Writer, то ничего не происходит, а вот он сам его исправно открывает. В общем, не всегда понятно, кто виноват в невозможности открыть файл в программе, проводник, другие части ОС или сама программа? Что тут скажешь, MS во всей красе.

[fedorro]

То что они открываются - это не в проводнике дело, а в открывающих программах, в основном. Проводник файловые операции не может выполнять: копирование, перемещение, удаление переименование.