Windows Server 2012 R2 Datacenter Windows Server 2012 R2 Essentials Windows Server 2012 R2 Foundation Windows Server 2012 R2 Standard Windows 8.1 Enterprise Windows 8.1 Pro Windows 8.1 Windows Server 2012 Datacenter Windows Server 2012 Datacenter Windows Server 2012 Standard Windows Server 2012 Standard Windows Server 2012 Essentials Windows Server 2012 Foundation Windows Server 2012 Foundation Windows 8 Enterprise Windows 8 Pro Windows 8 Windows 7 Service Pack 1 Windows Server 2008 R2 Service Pack 1 Еще…Меньше
Симптомы
Рассмотрим следующий сценарий:
-
У вас есть компьютер под управлением Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012 Пакет обновления 1 (SP1) для Windows 7 или Windows Server 2008 R2 Пакет обновления 1 (SP1).
-
Попробуйте скопировать файлы или папки, чтобы вставить их в другую папку с помощью проводника Windows.
-
Файлы или папки, которые вы поместите имеют пути, длина которых превышает максимальную допустимую длину пути.
В этом случае проведение операции копирования является ненадежным и происходит сбой из-за длины пути файла или папки. Кроме того возможно возникновение следующих проблем:
-
Операция копирования не выполняется и генерирует сообщение о том, что указан слишком длинный путь (имя файла). Сообщение также предлагает Сократите имя файла и повторите попытку копирования.
-
Операция копирования не запускается. В этом случае сообщение не формируется.
-
Операция копирования начинается, копирует несколько файлов или папок и затем завершается неудачей без выдачи сообщения.
Эта проблема может препятствовать копированию некоторых файлов или папок. Отсутствие сообщений об ошибке не свидетельствует об отсутствии ошибки в системе. Различные проблемы могут возникнуть в зависимости от того, как файлы выбраны для копирования.
Примечание. Эта проблема также может возникнуть при попытке копирования файлов и папок из моментальных снимков службы теневого копирования тома, если длина файла или папки в моментальном снимке, превышает максимальную длину пути.
Причина
Эта проблема возникает из-за особенности в способе обработки Windows ошибок длинных путей.
Решение
Для решения этой проблемы для Windows 8.1, Windows Server 2012 R2, Windows 8, andWindows Server 2012 установите накопительный пакет обновления.
Для решения этой проблемы для Windows 7 и Windows Server 2008 R2, установите исправление, описанное в данной статье.
Сведения об обновлении для Windows 8.1, Windows Server 2012 R2, Windows Server 2012 и Windows 8
Для решения этой проблемы установите накопительный пакет обновления, выпущенного апрель 2012 г. и 2014 ноября.
-
Windows RT 8.1, Windows 8.1 и обновления Windows Server 2012 R2: апреля 2014 г
-
Получить ноябрь 2014 накопительный пакет обновления для Windows Server 2012, Windows 8 и Windows RT
Сведения об исправлении для Windows 7 и Windows Server 2008 R2
Доступно исправление от службы поддержки Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы просмотреть полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:
http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Для установки этого исправления необходимо иметь Пакет обновления 1 для Windows 7 или Windows Server 2008 R2 установлен.
Необходимость перезагрузки
После установки исправления компьютер необходимо перезагрузить.
Сведения о замене исправлений
Это исправление не заменяет все ранее выпущенные исправления.
Английский (США) версия данного исправления устанавливает файлы с атрибутами, указанными в приведенных ниже таблицах. Дата и время для файлов указаны в формате UTC. Дата и время для файлов на локальном компьютере отображаются в местном времени с вашим текущим смещением летнего времени (DST). Кроме того, при выполнении определенных операций с файлами, даты и время могут изменяться.
Информация о файлах для Windows 7 и Windows Server 2008 R2 и примечанияВажно. Исправления для Windows Server 2008 R2 и Windows 7 включены в одни и те же пакеты. Однако исправления на странице запроса исправлений перечислены под обеими операционными системами. Чтобы запросить пакет исправления, который применяется к одной или обеим ОС, установите исправление, описанное в разделе «Windows 7/Windows Server 2008 R2» страницы. Всегда смотрите раздел «Информация в данной статье относится к следующим продуктам» статьи для определения фактических операционных систем, к которым применяется каждое исправление.
-
Файлы, относящиеся к определенному продукту, этапу разработки (RTM, SPn) и направлению поддержки (LDR, GDR) можно определить путем проверки номера версий файлов, как показано в следующей таблице.
Версия
Продукт
SR_Level
Направление поддержки
6.1.760
1.
22 xxxWindows 7 и Windows Server 2008 R2
SP1
LDR
-
Выпуски обновлений GDR содержат только те исправления, которые выпускаются повсеместно и предназначены для устранения распространенных крайне важных проблем. В обновления LDR входят также специализированные исправления.
-
Файлы MANIFEST (.manifest) и MUM (.mum), устанавливаемые для каждой среды, указаны отдельно в разделе «Сведения о дополнительных файлах для Windows 7 и Windows Server 2008 R2». Файлы MUM и MANIFEST, а также связанные файлы каталога безопасности (CAT) чрезвычайно важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не перечислены атрибуты, подписаны цифровой подписью корпорации Майкрософт.
Для всех поддерживаемых 86-разрядных версий Windows 7
Имя файла |
Версия файла |
Размер файла |
Дата |
Время |
Платформа |
---|---|---|---|---|---|
Shell32.dll |
6.1.7601.22503 |
12,875,776 |
06-Nov-2013 |
08:00 |
x86 |
Для всех поддерживаемых 64-разрядных версий Windows 7 и Windows Server 2008 R2
Имя файла |
Версия файла |
Размер файла |
Дата |
Время |
Платформа |
---|---|---|---|---|---|
Shell32.dll |
6.1.7601.22503 |
14,177,792 |
06-Nov-2013 |
08:51 |
x64 |
Shell32.dll |
6.1.7601.22503 |
12,875,776 |
06-Nov-2013 |
08:00 |
x86 |
Для всех поддерживаемых версий Windows Server 2008 R2 для систем на базе процессоров IA-64
Имя файла |
Версия файла |
Размер файла |
Дата |
Время |
Платформа |
---|---|---|---|---|---|
Shell32.dll |
6.1.7601.22503 |
21,196,800 |
06-Nov-2013 |
07:58 |
IA-64 |
Shell32.dll |
6.1.7601.22503 |
12,875,776 |
06-Nov-2013 |
08:00 |
x86 |
Статус
Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».
Сведения о дополнительных файлах для Windows 7 и Windows Server 2008 R2
Дополнительные файлы для всех поддерживаемых 86-разрядных версий Windows 7
Имя файла |
X86_5d28b9c19d39486a1a7e115506261602_31bf3856ad364e35_6.1.7601.22503_none_8fa29bae8b68a3a7.manifest |
Версия файла |
Неприменимо |
Размер файла |
695 |
Дата (UTC) |
06-Nov-2013 |
Время (UTC) |
14:55 |
Платформа |
Неприменимо |
Имя файла |
X86_microsoft-windows-shell32_31bf3856ad364e35_6.1.7601.22503_none_6ec3e88889548dc6.manifest |
Версия файла |
Неприменимо |
Размер файла |
1,059,457 |
Дата (UTC) |
06-Nov-2013 |
Время (UTC) |
10:12 |
Платформа |
Неприменимо |
Дополнительные файлы для всех поддерживаемых версий x64 под управлением Windows 7 и Windows Server 2008 R2
Имя файла |
Amd64_228d6e6efa0f144b0e3153891fddec59_31bf3856ad364e35_6.1.7601.22503_none_3f69116101f5cf33.manifest |
Версия файла |
Неприменимо |
Размер файла |
699 |
Дата (UTC) |
06-Nov-2013 |
Время (UTC) |
14:56 |
Платформа |
Неприменимо |
Имя файла |
Amd64_ab8a5a310911f0a583d4c1b8a0642dba_31bf3856ad364e35_6.1.7601.22503_none_400593ee3163c592.manifest |
Версия файла |
Неприменимо |
Размер файла |
1,040 |
Дата (UTC) |
06-Nov-2013 |
Время (UTC) |
14:56 |
Платформа |
Неприменимо |
Имя файла |
Amd64_microsoft-windows-shell32_31bf3856ad364e35_6.1.7601.22503_none_cae2840c41b1fefc.manifest |
Версия файла |
Неприменимо |
Размер файла |
1,058,443 |
Дата (UTC) |
06-Nov-2013 |
Время (UTC) |
09:16 |
Платформа |
Неприменимо |
Имя файла |
Wow64_microsoft-windows-shell32_31bf3856ad364e35_6.1.7601.22503_none_d5372e5e7612c0f7.manifest |
Версия файла |
Неприменимо |
Размер файла |
1,054,916 |
Дата (UTC) |
06-Nov-2013 |
Время (UTC) |
08:14 |
Платформа |
Неприменимо |
Дополнительные файлы для всех поддерживаемых версий Windows Server 2008 R2 с архитектурой IA-64
Имя файла |
Ia64_bba4409f672758cfdaf3e6e43606e4d6_31bf3856ad364e35_6.1.7601.22503_none_d273341408e6cde2.manifest |
Версия файла |
Неприменимо |
Размер файла |
1,038 |
Дата (UTC) |
06-Nov-2013 |
Время (UTC) |
14:55 |
Платформа |
Неприменимо |
Имя файла |
Ia64_microsoft-windows-shell32_31bf3856ad364e35_6.1.7601.22503_none_6ec58c7e895296c2.manifest |
Версия файла |
Неприменимо |
Размер файла |
1,058,441 |
Дата (UTC) |
06-Nov-2013 |
Время (UTC) |
08:22 |
Платформа |
Неприменимо |
Имя файла |
Wow64_microsoft-windows-shell32_31bf3856ad364e35_6.1.7601.22503_none_d5372e5e7612c0f7.manifest |
Версия файла |
Неприменимо |
Размер файла |
1,054,916 |
Дата (UTC) |
06-Nov-2013 |
Время (UTC) |
08:14 |
Платформа |
Неприменимо |
Ссылки
Узнайте о терминологии Корпорация Майкрософт использует для описания обновлений программного обеспечения.
Нужна дополнительная помощь?
в ОС windows есть очень старая и большая проблема, полный имя файла или папки не может превышать 259 символов.
есть обходной путь решения этой проблемы это подключение к папки как сетевого диска для сокращения пути, но это лишь костыль нормально работать все равно нельзя.
мелкомягкие выпустили типа патч https://support.microsoft.com/en-us/kb/2891362 где заявляют что данная проблема решена.
в итоге переходя по разным ссылкам получаем что нам необходимо скачать и установить следующие обновления:
https://www.microsoft.com/en-us/download/details.aspx?id=42334
Windows8.1-KB2919355-x64.msu
Windows8.1-KB2932046-x64.msu
Windows8.1-KB2934018-x64.msu
Windows8.1-KB2937592-x64.msu
Windows8.1-KB2938439-x64.msu
Windows8.1-KB2959977-x64.msu
В итоге имеем windows server 2012r2 все обновления установлены, работать с длинными именами файлами нельзя.
установили все в нужном порядке как требуется: These KB’s must be installed in the following
order: clearcompressionflag.exe, KB2919355, KB2932046, KB2959977, KB2937592, KB2938439, and KB2934018
Вопрос: что необходимо настроить, установить, удалить для корректной работы ОС с длинными именами?
-
Изменено
10 декабря 2015 г. 13:45
дополнил -
Изменен тип
Petko KrushevMicrosoft contingent staff, Moderator
13 января 2016 г. 8:17
- Remove From My Forums
-
Question
-
Hi
Recently I replaced a branch office server migrating the services from 2008 R2 to 2012 R2. One of the services is the File Server role. The server is a Hyper-V guest with a file storage area on its own .vhdx. When I migrated the files from the old 2008 R2
server, rather than reconnect the old .vhd, I decided to create the new one as a .vhdx and use DFSR to replicate the folders and files.All the migration occured without a hitch and the other server has been decommisioned. However, it’s come to light that files on long file paths, that could be opened on the 2008 R2 server can no longer be worked with on the 2012 R2 server.
No matter whether we try to open, copy, move or even delete the file, we get a «Filename too long» error.
Now, the file paths are too long admittedly. For example, the file the office is particularly interested in accessing is 283 characters in length including the filepath. I’ve advised they rename folders further up the tree to bring it under 255 characters
but I’m interested in finding out why they were accessible on the 2008 R2 server and not the 2012 R2 server.Any insight would be greatly appreciated.
David
Answers
-
Hi David,
Thanks for your post.Sometimes the issue may related to 8dot3 short namr creation.
It may appear that disabled the 8dot3 short name creation bit in 2012 R2. All our 2008 R2 file servers had this bit enabled by default.You can check the status of a volume using: fsutil behavior query disable8dot 3. If it’s disable try to
enable and reboot to have a check
https://technet.microsoft.com/en-us/library/cc785435.aspxIf it still doesn’t work, you might need to rename the folder, it might to be the limition by design.
Best Regards,
Mary
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
-
Edited by
Thursday, July 21, 2016 1:55 AM
-
Proposed as answer by
Mary Dong
Thursday, July 28, 2016 8:36 AM -
Marked as answer by
Mary Dong
Monday, August 1, 2016 8:53 AM
-
Edited by
- Remove From My Forums
-
Question
-
Hi
Recently I replaced a branch office server migrating the services from 2008 R2 to 2012 R2. One of the services is the File Server role. The server is a Hyper-V guest with a file storage area on its own .vhdx. When I migrated the files from the old 2008 R2
server, rather than reconnect the old .vhd, I decided to create the new one as a .vhdx and use DFSR to replicate the folders and files.All the migration occured without a hitch and the other server has been decommisioned. However, it’s come to light that files on long file paths, that could be opened on the 2008 R2 server can no longer be worked with on the 2012 R2 server.
No matter whether we try to open, copy, move or even delete the file, we get a «Filename too long» error.
Now, the file paths are too long admittedly. For example, the file the office is particularly interested in accessing is 283 characters in length including the filepath. I’ve advised they rename folders further up the tree to bring it under 255 characters
but I’m interested in finding out why they were accessible on the 2008 R2 server and not the 2012 R2 server.Any insight would be greatly appreciated.
David
Answers
-
Hi David,
Thanks for your post.Sometimes the issue may related to 8dot3 short namr creation.
It may appear that disabled the 8dot3 short name creation bit in 2012 R2. All our 2008 R2 file servers had this bit enabled by default.You can check the status of a volume using: fsutil behavior query disable8dot 3. If it’s disable try to
enable and reboot to have a check
https://technet.microsoft.com/en-us/library/cc785435.aspxIf it still doesn’t work, you might need to rename the folder, it might to be the limition by design.
Best Regards,
Mary
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
-
Edited by
Thursday, July 21, 2016 1:55 AM
-
Proposed as answer by
Mary Dong
Thursday, July 28, 2016 8:36 AM -
Marked as answer by
Mary Dong
Monday, August 1, 2016 8:53 AM
-
Edited by
Обновлено 28.11.2020
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Pyatilistnik.org. В прошлый раз мы с вами разобрали возможности утилиты PING, рассмотрели как ее применять на практике. В сегодняшней публикации я вам покажу, как устраняется боль и печаль в операционных системах Windows, я говорю про длинные пути, в своей практике я очень часто встречал жалобы «Слишком длинный целевой путь» или «Слишком длинный конечный путь«, то же самое вы можете встретить и при удалении. Ниже я покажу, как выкручиваться из данной ситуации.
Описание проблемы длинных путей
Раньше имена файлов в Windows ограничивались форматом 8.3 — всего восемь символов для имени файла и три для расширения. С появлением Windows 95 Microsoft сняла этот предел и позволила использовать гораздо более длинные имена.
Тем не менее, файловая система Windows по-прежнему накладывает некоторые ограничения, например, какие символы могут использоваться в именах файлов и общую длину путей. Некоторое время максимальная длина пути составляла 260 символов, но с появлением Windows 10, часть ограничений начала потихоньку уходить, например для приложений и появилась возможность отключить проверку MAX_PATH и использовать длинные пути без префикса \?.
Что интересно, значение в 260 символов обусловлено значением MAX_PATH Win32 API. У файловой системы NTFS максимальная длина пути ″немного″ больше и составляет 32767 символа. Для обхода ограничений Win32 API некоторые приложения используют формат UNC, указывая абсолютный путь с префиксом \?, например так:
\?C:директорияподдиректорияимя файла
Хочу отметить, что на период ноября 2020 года и последней версий Windows 10 1909, в ПРОВОДНИКЕ Windows до сих пор есть ограничения в 260 символов, и мы все слышим обещания, что их исправят
Большинство людей может и не столкнуться с ней, а вот почти каждый системный администратор обязательно это увидит. Тут все дело в том, что в большинстве организаций есть свои сетевые файловые ресурсы, через которые пользователи производят обмен и работу с документами. В какой-то момент люди могут создать такой путь, который будет 258 или 260 символов, попытаются туда скопировать файл, а им выдастся ошибка:
Слишком длинный целевой путь: Имена файлов слишком длинны для помещения в эту целевую папку. Попробуйте использовать более короткое имя имя файла или расположение с более коротким путем
Тоже самое при копировании в папку, так же выскакивает «Слишком длинный целевой путь».
Вот ошибка при извлечении архива в сетевую папку:
Не удается завершить извлечение. Слишком длинный конечный путь. Переименуйте сжатую ZIP-папку и повторите попытку
Методы снимающие ограничения на длину пути в Windows
- Через групповую или локальную политику Windows (Применимо только к Windows 10 и Windows Server 2016 и выше)
- Через реестр Windows (Применимо только к Windows 10 и Windows Server 2016 и выше)
- Через сторонние утилиты 7-Zip, Far, TotalCommander (Применимо ко всем версиям Windows)
- Использование силинков (символических ссылок) (Применимо ко всем версиям Windows)
- Через сетевой диск, для укорачивания пути
- Утилиты xcopy, robocopy
Нюансы длинных путей в приложениях
Есть один нюанс. Этот новый параметр (имеется ввиду та политика и ключ реестра) не обязательно будет работать со всеми существующими приложениями, но он будет работать с большинством. В частности, любые современные приложения должны работать нормально, как и все 64-битные приложения. Старые 32-разрядные приложения должны быть применимы для работы, что на самом деле просто означает, что разработчик указал в файле манифеста приложения, что приложение поддерживает более длинные пути. Большинство популярных 32-битных приложений не должно вызывать проблем. Тем не менее, вы ничем не рискуете, пробуя настройку. Если приложение не работает, единственное, что произойдет, это то, что оно не сможет открывать или сохранять файлы, сохраненные в местах, где полный путь превышает 260 символов.
Если вы разработчик, то чтобы ваше приложение имело возможность работать с длинными путями Windows, в манифесте обязательно указывайте следующие настройки:
<application xmlns=»urn:schemas-microsoft-com:asm.v3″>
<windowsSettings>
<longPathAware xmlns=»http://schemas.microsoft.com/SMI/2016/WindowsSettings»>true</longPathAware>
</windowsSettings>
</application>
Как в Windows 10 отключить ограничение на длину пути в 260 символов через политику
Чем примечателен данный метод, так это тем, что неподготовленных пользователей он не вынуждает выполнять команды или производить правку реестра, тут все в графическом виде. Так же если у вас есть домен Active Directory и вы хотите массово убрать ошибки «Слишком длинный целевой путь» или «Слишком длинный конечный путь» в приложениях и запретить им проверять MAX_PATH и использовать длинные пути без префикса \?, то групповые политики вам это помогут.
Еще раз напоминаю, что данный метод подойдет и для серверных версий, даже самых современных Windows Server 2019
Покажу для начала, как делать через локальную политику, открываете окно «Выполнить» в котором пишите gpedit.msc.
Хочу отметить, что для Windows 10 Home данный метод работать не будет, там просто нет редактора локальных политик, там придется лезть в реестр Windows
Далее идем по пути:
Конфигурация компьютера — Административные шаблоны — Система — Файловая система (Computer configuration — Administrative templates — System — Filesystem)
Найдите тут параметр «Включить длинные пути Win32 (Enable Win32 long paths)«, по умолчанию он отключен, и я честно не понимаю почему. Активируйте его.
То же самое вы можете сделать централизовано для массового управления через групповые политики, все ветки те же самые.
Как я писал выше, в проводнике это не даст ни каких эффектов, поэтому вы все так же будите получать ошибку при копировании, создании, удалении «Слишком длинный целевой путь» или «Слишком длинный конечный путь«. Ниже я покажу, что делать если нужно что-то там удалить или изменить. Данное ограничение в длине пути теперь не подхватиться на лету всеми приложениями, потребуется перезагрузка.
Включение поддержки длинных путей через реестр
Данный метод ни чуть не сложнее предыдущего и делает все то же самое, включает поддержку длинных путей свыше 256 символов для приложений Windows. Когда вы что-то меняете через редактор политик, по сути меняются настройки в реестре, это нужно помнить и знать. Сейчас я вам покажу какой ключ меняется. Откройте редактор реестра Windows. Перейдите в раздел:
HKLMSystemCurrentControlSetControlFileSystem
тут вам необходимо найти параметр LongPathEnabled, которому для активации поддержки длинных путей и изменения ограничений в MAX_PATH, нужно задать значение «1». Тут потребуется перезагрузка.
Все что вам нужно, это распаковать zip-архив и запустить нужный файл активации, потом так же перезагрузиться, так как у вас будет создан нужный ключ реестра, без необходимости лезть в реестр самостоятельно.
Еще вы можете сделать такую поддержку и для конкретного пользователя по пути:
HKEY_CURRENT_USERSOFTWAREMicrosoftWindows CurrentVersionGroup Policy Objects {48981759-12F2-42A6-A048-028B3973495F} MachineSystemCurrentControlSetPolicies
Если там нет ключа LongPathsEnabled, то создайте его, тип DWORD (32 бита) и значение 1.
Как в Windows 10 отключить ограничение на длину пути в 260 символов через PowerShell
Не все люди готовы копаться в редакторах и реестрах, им нужно быстрое решение, одним из таких является PowerShell. В оболочке выполните команду для активации параметра «Включить длинные пути Win32 (LongPathEnabled)». Не забываем перезагрузить систему.
Set-ItemProperty -Path HKLM:SYSTEMCurrentControlSetControlFileSystem -Name LongPathsEnabled -Value 1
Как удалять, копировать, переносить файлы и папки при ошибке с длинными путями
Разобравшись с тем, как отключить проверку MAX_PATH в приложениях, давайте теперь поймем и научимся решать проблему длинных путей на файловых шарах и просто в проводнике. Классическая ситуация, когда пользователь попытался перенести свой файл или удалить его, создать папку и так далее, и он получает ошибку с пресловутыми длинными путями. Он просит разобраться вас и тут начинаются танцы с бубнами, вы просите его либо переименовать часть пути, или попросить его произвести действия в другом расположении, или просто забить, сказав, что виновата Windows со своими ограничениями, но мы же с вами профессионалы и инженеры, поэтому должны уметь выходить из таких ситуаций.
Как в Windows 10 отключить ограничение на длину пути в 260 символов через командную строку
Запустите командную строку в режиме администратора и введите:
reg add «HKLMSYSTEMCurrentControlSetControlFileSystem» /v LongPathsEnabled /t REG_DWORD /d 1
Потребуется перезагрузка.
Обход ограничений длинных путей через 7zFM
Наверняка многие знают архиватор 7Zip, но мало кто пользуется его файловым менеджером 7zFM.exe, а зря именно он может вам помочь в ситуации с сообщением «Слишком длинный целевой путь» или «Слишком длинный конечный путь». Вот у меня есть тестовая директория, у которой уже есть 260 символов в пути, и я не могу там создавать новую папку.
Откройте 7zFM.exe и перейдите в нем в конечную папку вашего пути.
Для создания новой папки нажмите клавишу F7.
Задайте необходимое вам имя, в моем примере это будет «БОльше 260 Microsot«.
В результате у нас создалась новая папка и заметьте 7zFM не ругнулся на наличие длинных путей, он их игнорирует просто и все.
Проверяем, что директория доступна через проводник Windows.
Все прекрасно отображается. Теперь я думаю вы легко сможете переносить, копировать, удалять файлы через 7zFM, когда вам проводник Windows ругается на наличие длинных путей.
Как обойти ограничение длинных путей через символьную ссылку
Такой трюк мы с вами уже проделывали, когда нужно было переносить IMAP профиль у Outlook. Смысл в том, что создается файл в нужном вам месте, и этот файл это просто ярлык ссылающийся на нужный вам файл или папку, после этого путь сокращается и вы можете удалять или создавать все что вам нужно. Откройте командную строку, далее вам нужно иметь два составляющих:
- Путь где будет лежать файл символической ссылки — в моем примере C:короткий путь
- Длинный путь — C:ShareWINDOW~1C73D~1C6BF~1 D915~15C04~1B4E5~1260MIC~1
Нам поможет команда mklink, где ключ /D создает ссылку на каталог
mklink /D «C:короткий путь» «C:ShareWINDOW~1 C73D~1C6BF~1D915~15C04~1B4E5~1260MIC~1»
Символическая ссылка успешно создана, можно проверять.
Откройте каталог с укороченным путем и попробуйте создать просто папку, в итоге она будет создана именно по тому длинному пути, как видите легко можно обходить ограничение в 260 символов.
Как обойти ограничение длинных путей через сопоставление subst
subst — простая команда позволяющая связать нужный путь к каталогу с буквой диска. Так же откройте командную строку в режиме администратора и сопоставьте ваш длинный путь с буквой W.
subst W: «C:ShareWINDOW~1C73D~1C6BF~1 D915~15C04~1B4E5~1260MIC~1»
У вас в проводнике Windows должен появиться диск с данной буквой, если его нет, то прочитайте статью «Не появляется диск после команды subst» или просто в проводнике вбейте W: и нажмите Enter.
Как обойти ограничение длинных путей через монтирование сетевого диска
В командной строке используйте команду net use, далее буква диска, которую мы присваиваем и в самом конце путь:
net use Z: «\DESKTOP-OJ0SCOEShareWINDOW~1 C73D~1C6BF~1D915~15C04~1B4E5~1260MIC~1» /persistent:yes
Как видим все прекрасно отработало и диск появился.
Использование утилит Far или Total Commander
После включения параметра «Включить длинные пути Win32» данные утилиты в 100% случаев помог вам произвести любые действия с папками или файлами на любом длинном пути в системе Windows. Откройте Total Commander и создайте для примера папку в каталоге с длинным путем, напоминаю для этого нужно нажать F7.
Как видите все прекрасно создается, удаляется или копируется при желании.
Как еще обойти проблему с длинными путями Windows
В мир виртуализации и облаков, многие компании переносят свои файловые ресурсы именно туда. Например в моей компании используют для хранения большинства данных это Google Drive, кто-то диски mail.ru или Яндекса, не нужно этого бояться, главное смотрите, чтобы это подходило с юридической точки зрения но и не нужно лукавить это может стоить дополнительных расходов, но зато ни каких длинных путей, вышедших из строя дисков в RAID, место наращивается на лету, короче одни плюсы.
На этом у меня все, мы разобрали как исправляются ошибки «Слишком длинный целевой путь» или «Слишком длинный конечный путь«, с вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
-
#1
Переношу данные с файлового сервера на Windows 2012R2 на Truenas.
Выяснилось, что Truenas не нравятся длинные имена файлов.
По крайней мере, при копировании по SMB.
При попытке скопировать файл с именем вида RE_ Северо-Осетинский филиал АО _АльфаСтрахование__ уведомление о поступившем требовании потерпевшего по полису ОСАГО ХХХ00123456789 Фамилия И_О_.msg
Получаем ошибку вида «Указано неправильное или слишком длинное имя файла»,
Это и в проводнике, и через robocopy.
Копируем прямо в корень SMB шары.
Если копировать этот же файл в SMB шару на WIndows — все копируется нормально.
Ограничения ZFS?
Можно ли это как то дополнительно настроить?
К сожалению, отказаться от этих длинных имен файлов никак, они привязаны в информационной системе компании.
-
#2
А через префикс \? Тоже не получается ?
-
#3
Опытным путем выяснил следующее.
В консоли получилось создать файл с именем, максимальная длина которого 146 символов.
Если имя длиннее, получаем сообщение File name too long
Наткнулся на обсуждение 2014 года https://github.com/openzfs/zfs/issues/2344
Проблема в том, что кириллические имена в UTF занимают в два раза больше байт.
Т.е. если имя файла 146 символов, то получается 292 символа.
Но почему дает создать файл с именем из 145 символов? Это 290 байт.
Понравился еще комментарий https://forum.lissyara.su/networks-f4/problema-s-rsync-file-name-too-long-t34772.html:
«Чёрт возьми. Файловая система ZFS с поддержкой триллиардов петабайтовых пулов и бесконечных чисел снапсшотов и ещё огромных количеств и объёмов всего на свете. И такое ничтожное ограничение, из-за которого появляется такая маленькая, но гадостная проблемка. Непонятно»
И еще интересное решение и краткой теорией https://wiki.etersoft.ru/Linux/VLFN
В общем, печально это.
-
#4
В итоге решил обработать массив исходных файлов перед копированием скриптом на powershell вида
Get-ChildItem -Recurse -File | Where-Object {$_.Name.Length -gt 145} | ForEach-Object{
Write-Output «Длина имени файла $($_.FullName) равна $($_.Name.Length)»
Add-Content lenght.txt «Длина имени файла $($_.FullName) равна $($_.Name.Length)»
Rename-Item -Path $_.FullName -NewName ( ($_.Name -replace ‘(?<=^.{140}).*$’) + $_.Extension )
}
Две строки в скрипте только для отладки и журналирования.
Так вроде работает.
Но powershell также может столкнуться с ошибкой вида
Get-ChildItem : Слишком длинный путь или имя файла. Полное имя файла должно содержать меньше 260 знаков, а имя каталога — меньше 248 знаков.
Есть решение https://habr.com/ru/post/457204/
Но сам пока не применял, так как пока нет возможности перезагрузить исходный сервер.
-
#5
В тоталкоммандере есть класная фича Групповое переименовывание, там можно задать число знаков в имени файла и всё что выходи за он отрезает. Это, конечно, не то решение, которое хотелось бы, но всё ж.
-
#6
Ну да, тоже вариант.
Единственно, с тоталом почти не сталкивался, поэтому решил сделать на powershell тоже самое )
В тотале можно указать каталог, в котором куча подкаталогов, и так на несколько уровней, при этом неизвестно, где могут быть подобные файлы?
-
#7
Точно не помню как искал длинные имена, но сейчас на гуглил плагин для тотала FileX, там в свойствах есть Длина пути и <>=.
Глубину вложения файлов так же можно задать.
Содержание
- Как убрать запрет на копирование файлов с длинными именами в windows
- Описание проблемы длинных путей
- Методы снимающие ограничения на длину пути в Windows
- Нюансы длинных путей в приложениях
- Как в Windows 10 отключить ограничение на длину пути в 260 символов через политику
- Включение поддержки длинных путей через реестр
- Как в Windows 10 отключить ограничение на длину пути в 260 символов через PowerShell
- Как удалять, копировать, переносить файлы и папки при ошибке с длинными путями
- Как в Windows 10 отключить ограничение на длину пути в 260 символов через командную строку
- Обход ограничений длинных путей через 7zFM
- Как обойти ограничение длинных путей через символьную ссылку
- Сбой операции копирования файлов, если у файлов или папок длинные пути, в проводнике
- Симптомы
- Причина
- Решение
- Сведения об обновлении для Windows 8.1, Windows Server 2012 R2, Windows Server 2012 и Windows 8
- Сведения об исправлении для Windows 7 и Windows Server 2008 R2
- Предварительные условия
- Необходимость перезагрузки
- Сведения о замене исправлений
- Статус
- Ссылки
- Выбираем длинный путь (или прощай MAX_PATH)
- Приложения Win API
- .Net Framework
- .Net Core
- Как включить поддержку длинных путей в Windows 10 (1607)
- Как исправить проблему «Имя файла слишком длинное» в Windows
- Почему длина имени файла является проблемой в Windows?
- Настройка Windows 10 на обработку длинных путей к файлам
- Параметры для Windows 10 Home
- Параметры для Windows 10 Pro или Enterprise
- Как временно исправить проблему с файлами?
- Легкое Исправление
- Менее простые исправления
Как убрать запрет на копирование файлов с длинными именами в windows
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Pyatilistnik.org. В прошлый раз мы с вами разобрали возможности утилиты PING, рассмотрели как ее применять на практике. В сегодняшней публикации я вам покажу, как устраняется боль и печаль в операционных системах Windows, я говорю про длинные пути, в своей практике я очень часто встречал жалобы «Слишком длинный целевой путь» или «Слишком длинный конечный путь«, то же самое вы можете встретить и при удалении. Ниже я покажу, как выкручиваться из данной ситуации.
Описание проблемы длинных путей
Тем не менее, файловая система Windows по-прежнему накладывает некоторые ограничения, например, какие символы могут использоваться в именах файлов и общую длину путей. Некоторое время максимальная длина пути составляла 260 символов, но с появлением Windows 10, часть ограничений начала потихоньку уходить, например для приложений и появилась возможность отключить проверку MAX_PATH и использовать длинные пути без префикса \?.
Что интересно, значение в 260 символов обусловлено значением MAX_PATH Win32 API. У файловой системы NTFS максимальная длина пути ″немного″ больше и составляет 32767 символа. Для обхода ограничений Win32 API некоторые приложения используют формат UNC, указывая абсолютный путь с префиксом \?, например так:
Большинство людей может и не столкнуться с ней, а вот почти каждый системный администратор обязательно это увидит. Тут все дело в том, что в большинстве организаций есть свои сетевые файловые ресурсы, через которые пользователи производят обмен и работу с документами. В какой-то момент люди могут создать такой путь, который будет 258 или 260 символов, попытаются туда скопировать файл, а им выдастся ошибка:
Тоже самое при копировании в папку, так же выскакивает «Слишком длинный целевой путь».
Вот ошибка при извлечении архива в сетевую папку:
Методы снимающие ограничения на длину пути в Windows
Нюансы длинных путей в приложениях
Есть один нюанс. Этот новый параметр (имеется ввиду та политика и ключ реестра) не обязательно будет работать со всеми существующими приложениями, но он будет работать с большинством. В частности, любые современные приложения должны работать нормально, как и все 64-битные приложения. Старые 32-разрядные приложения должны быть применимы для работы, что на самом деле просто означает, что разработчик указал в файле манифеста приложения, что приложение поддерживает более длинные пути. Большинство популярных 32-битных приложений не должно вызывать проблем. Тем не менее, вы ничем не рискуете, пробуя настройку. Если приложение не работает, единственное, что произойдет, это то, что оно не сможет открывать или сохранять файлы, сохраненные в местах, где полный путь превышает 260 символов.
Если вы разработчик, то чтобы ваше приложение имело возможность работать с длинными путями Windows, в манифесте обязательно указывайте следующие настройки:
Как в Windows 10 отключить ограничение на длину пути в 260 символов через политику
Чем примечателен данный метод, так это тем, что неподготовленных пользователей он не вынуждает выполнять команды или производить правку реестра, тут все в графическом виде. Так же если у вас есть домен Active Directory и вы хотите массово убрать ошибки «Слишком длинный целевой путь» или «Слишком длинный конечный путь» в приложениях и запретить им проверять MAX_PATH и использовать длинные пути без префикса \?, то групповые политики вам это помогут.
Покажу для начала, как делать через локальную политику, открываете окно «Выполнить» в котором пишите gpedit.msc.
Далее идем по пути:
Найдите тут параметр «Включить длинные пути Win32 (Enable Win32 long paths)«, по умолчанию он отключен, и я честно не понимаю почему. Активируйте его.
Как я писал выше, в проводнике это не даст ни каких эффектов, поэтому вы все так же будите получать ошибку при копировании, создании, удалении «Слишком длинный целевой путь» или «Слишком длинный конечный путь«. Ниже я покажу, что делать если нужно что-то там удалить или изменить. Данное ограничение в длине пути теперь не подхватиться на лету всеми приложениями, потребуется перезагрузка.
Включение поддержки длинных путей через реестр
Данный метод ни чуть не сложнее предыдущего и делает все то же самое, включает поддержку длинных путей свыше 256 символов для приложений Windows. Когда вы что-то меняете через редактор политик, по сути меняются настройки в реестре, это нужно помнить и знать. Сейчас я вам покажу какой ключ меняется. Откройте редактор реестра Windows. Перейдите в раздел:
тут вам необходимо найти параметр LongPathEnabled, которому для активации поддержки длинных путей и изменения ограничений в MAX_PATH, нужно задать значение «1». Тут потребуется перезагрузка.
Все что вам нужно, это распаковать zip-архив и запустить нужный файл активации, потом так же перезагрузиться, так как у вас будет создан нужный ключ реестра, без необходимости лезть в реестр самостоятельно.
Еще вы можете сделать такую поддержку и для конкретного пользователя по пути:
Если там нет ключа LongPathsEnabled, то создайте его, тип DWORD (32 бита) и значение 1.
Как в Windows 10 отключить ограничение на длину пути в 260 символов через PowerShell
Не все люди готовы копаться в редакторах и реестрах, им нужно быстрое решение, одним из таких является PowerShell. В оболочке выполните команду для активации параметра «Включить длинные пути Win32 (LongPathEnabled)». Не забываем перезагрузить систему.
Как удалять, копировать, переносить файлы и папки при ошибке с длинными путями
Разобравшись с тем, как отключить проверку MAX_PATH в приложениях, давайте теперь поймем и научимся решать проблему длинных путей на файловых шарах и просто в проводнике. Классическая ситуация, когда пользователь попытался перенести свой файл или удалить его, создать папку и так далее, и он получает ошибку с пресловутыми длинными путями. Он просит разобраться вас и тут начинаются танцы с бубнами, вы просите его либо переименовать часть пути, или попросить его произвести действия в другом расположении, или просто забить, сказав, что виновата Windows со своими ограничениями, но мы же с вами профессионалы и инженеры, поэтому должны уметь выходить из таких ситуаций.
Как в Windows 10 отключить ограничение на длину пути в 260 символов через командную строку
Запустите командную строку в режиме администратора и введите:
Обход ограничений длинных путей через 7zFM
Наверняка многие знают архиватор 7Zip, но мало кто пользуется его файловым менеджером 7zFM.exe, а зря именно он может вам помочь в ситуации с сообщением «Слишком длинный целевой путь» или «Слишком длинный конечный путь». Вот у меня есть тестовая директория, у которой уже есть 260 символов в пути, и я не могу там создавать новую папку.
Откройте 7zFM.exe и перейдите в нем в конечную папку вашего пути.
Для создания новой папки нажмите клавишу F7.
Задайте необходимое вам имя, в моем примере это будет «БОльше 260 Microsot«.
В результате у нас создалась новая папка и заметьте 7zFM не ругнулся на наличие длинных путей, он их игнорирует просто и все.
Проверяем, что директория доступна через проводник Windows.
Все прекрасно отображается. Теперь я думаю вы легко сможете переносить, копировать, удалять файлы через 7zFM, когда вам проводник Windows ругается на наличие длинных путей.
Как обойти ограничение длинных путей через символьную ссылку
Такой трюк мы с вами уже проделывали, когда нужно было переносить IMAP профиль у Outlook. Смысл в том, что создается файл в нужном вам месте, и этот файл это просто ярлык ссылающийся на нужный вам файл или папку, после этого путь сокращается и вы можете удалять или создавать все что вам нужно. Откройте командную строку, далее вам нужно иметь два составляющих:
Нам поможет команда mklink, где ключ /D создает ссылку на каталог
Источник
Сбой операции копирования файлов, если у файлов или папок длинные пути, в проводнике
Симптомы
Рассмотрим следующий сценарий:
У вас есть компьютер под управлением Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012 Пакет обновления 1 (SP1) для Windows 7 или Windows Server 2008 R2 Пакет обновления 1 (SP1).
Попробуйте скопировать файлы или папки, чтобы вставить их в другую папку с помощью проводника Windows.
Файлы или папки, которые вы поместите имеют пути, длина которых превышает максимальную допустимую длину пути.
В этом случае проведение операции копирования является ненадежным и происходит сбой из-за длины пути файла или папки. Кроме того возможно возникновение следующих проблем:
Операция копирования не выполняется и генерирует сообщение о том, что указан слишком длинный путь (имя файла). Сообщение также предлагает Сократите имя файла и повторите попытку копирования.
Операция копирования не запускается. В этом случае сообщение не формируется.
Операция копирования начинается, копирует несколько файлов или папок и затем завершается неудачей без выдачи сообщения.
Эта проблема может препятствовать копированию некоторых файлов или папок. Отсутствие сообщений об ошибке не свидетельствует об отсутствии ошибки в системе. Различные проблемы могут возникнуть в зависимости от того, как файлы выбраны для копирования.
Примечание. Эта проблема также может возникнуть при попытке копирования файлов и папок из моментальных снимков службы теневого копирования тома, если длина файла или папки в моментальном снимке, превышает максимальную длину пути.
Причина
Эта проблема возникает из-за особенности в способе обработки Windows ошибок длинных путей.
Решение
Для решения этой проблемы для Windows 8.1, Windows Server 2012 R2, Windows 8, andWindows Server 2012 установите накопительный пакет обновления.
Для решения этой проблемы для Windows 7 и Windows Server 2008 R2, установите исправление, описанное в данной статье.
Сведения об обновлении для Windows 8.1, Windows Server 2012 R2, Windows Server 2012 и Windows 8
Для решения этой проблемы установите накопительный пакет обновления, выпущенного апрель 2012 г. и 2014 ноября.
Сведения об исправлении для Windows 7 и Windows Server 2008 R2
Доступно исправление от службы поддержки Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы просмотреть полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:
Примечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Для установки этого исправления необходимо иметь для Windows 7 или Windows Server 2008 R2 установлен.
Необходимость перезагрузки
После установки исправления компьютер необходимо перезагрузить.
Сведения о замене исправлений
Это исправление не заменяет все ранее выпущенные исправления.
Английский (США) версия данного исправления устанавливает файлы с атрибутами, указанными в приведенных ниже таблицах. Дата и время для файлов указаны в формате UTC. Дата и время для файлов на локальном компьютере отображаются в местном времени с вашим текущим смещением летнего времени (DST). Кроме того, при выполнении определенных операций с файлами, даты и время могут изменяться.
Информация о файлах для Windows 7 и Windows Server 2008 R2 и примечанияВажно. Исправления для Windows Server 2008 R2 и Windows 7 включены в одни и те же пакеты. Однако исправления на странице запроса исправлений перечислены под обеими операционными системами. Чтобы запросить пакет исправления, который применяется к одной или обеим ОС, установите исправление, описанное в разделе «Windows 7/Windows Server 2008 R2» страницы. Всегда смотрите раздел «Информация в данной статье относится к следующим продуктам» статьи для определения фактических операционных систем, к которым применяется каждое исправление.
Файлы, относящиеся к определенному продукту, этапу разработки (RTM, SP n) и направлению поддержки (LDR, GDR) можно определить путем проверки номера версий файлов, как показано в следующей таблице.
Выпуски обновлений GDR содержат только те исправления, которые выпускаются повсеместно и предназначены для устранения распространенных крайне важных проблем. В обновления LDR входят также специализированные исправления.
Файлы MANIFEST (.manifest) и MUM (.mum), устанавливаемые для каждой среды, указаны отдельно в разделе «Сведения о дополнительных файлах для Windows 7 и Windows Server 2008 R2». Файлы MUM и MANIFEST, а также связанные файлы каталога безопасности (CAT) чрезвычайно важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не перечислены атрибуты, подписаны цифровой подписью корпорации Майкрософт.
Статус
Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».
Сведения о дополнительных файлах для Windows 7 и Windows Server 2008 R2
Дополнительные файлы для всех поддерживаемых 86-разрядных версий Windows 7
Ссылки
Узнайте о Корпорация Майкрософт использует для описания обновлений программного обеспечения.
Источник
Выбираем длинный путь (или прощай MAX_PATH)
Многим пользователям ПК под управлением ОС Windows, не говоря о разработчиках, знакомы проблемы при работе с длинными (более 260 символов, MAX_PATH) путями файлов или каталогов.
Приложения Win API
В приложениях, которые используют Win API для работы с файлами, рецепт избавления от ограничения MAX_PATH был известен с незапамятных времён – необходимо было использовать Unicode версию функции с окончанием «W» для работы с директорией или файлом и начинать путь с префикса \?. Это давало возможность использовать пути длинной до 32767 символов.
В Windows 10 (1607) поведение функций для работы с файлами изменилось: появилась возможность отключить проверку ограничений MAX_PATH на уровне системы.
Это избавляет от необходимости использовать префикса \? и потенциально даёт шанс приложениям, работающим напрямую или косвенно через Win API, получить поддержку длинных путей без необходимости их пересборки. Как активировать эту возможность описано в конце статьи.
.Net Framework
.Net Core
Тут поддержку длинных путей анонсировали ещё в ноябре 2015 года. Видимо сказалось Open Source природа проекта и отсутствие строгой необходимости обеспечения обратной совместимости.
Вот тут можно посмотреть пример.
Как включить поддержку длинных путей в Windows 10 (1607)
Эта возможность по умолчанию отключена. Это объясняется тем, что данная функция является экспериментальной, и имеется необходимость дорабатывать различные подсистемы и приложения для полной поддержки.
Включить встроенную поддержку длинных путей можно создав или изменив следующий параметр системного реестра: HKLMSYSTEMCurrentControlSetControlFileSystem Параметр LongPathsEnabled (Тип: REG_DWORD) 1 – соответствует значению включено.
Или через групповые политики (Win+Rgpedit.msc) Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths.Оно же в локализованном варианте: Конфигурация компьютера > Административные шаблоны > Система > Файловая система > Включить длинные пути Win32.
Далее источники расходятся во мнении относительно манифеста (или я неправильно понял, но на данный момент проверить не имею возможности). Например, в документации MSDN написано, что манифест можно использовать в качестве альтернативного способа активации поддержки длинных путей в отдельных приложениях, а в блоге MSDN указано, что это является вторым обязательным шагом после активации в политиках.
Но они сходятся в формате задания данной опции:
С CMD, к сожалению, это не сработает, на данный момент, из-за особенностей работы с путями, а в PowerShell должно всё заработать.
На этом мой небольшой пятничный пост заканчивается, оставив за рамками вопросы полноты реализации поддержки длинных путей в Windows 10 (1607), или работоспособность при использовании различных комбинаций редакций Windows, файловых систем и API. По мере поступления новых фактов и результатов экспериментов пост будет обновляться.
Источник
Как исправить проблему «Имя файла слишком длинное» в Windows
Если вы когда-либо видели эту проблему, это, вероятно, было простым решением для вас. Если вы видели эту ошибку более двух раз, то вы также знаете, что иногда это может быть сложной проблемой.
Будем надеяться, что вы столкнетесь только с набором легких исправлений, но мы подготовим вас к менее простым, гарантированно исправным исправлениям.
Почему длина имени файла является проблемой в Windows?
Существует большая история длины файлов, что является проблемой для операционных систем, таких как Windows. Было время, когда вы не могли иметь имена файлов длиннее 8 символов плюс 3-символьное расширение файла. Лучшее, что вы могли сделать, это что-то вроде myresume.doc. Это было ограничение в отношении дизайна файловой системы.
Все стало лучше, когда вышли новые версии Windows. Мы перешли от старой ограниченной файловой системы к так называемой файловой системе новой технологии (NTFS). NTFS привела нас к тому, что имя файла может быть длиной 255 символов, а длина пути к файлу потенциально может достигать 32 767 символов. Так как же мы можем иметь слишком длинные имена файлов?
В Windows есть вещи, известные как системные переменные. Это переменные, от которых зависит функционирование Windows, потому что Windows всегда будет знать, что означают переменные и где они находятся, даже когда мы перемещаем биты и байты повсюду. Системная переменная MAX_PATH — это та, которая ограничивает имена файлов и пути к файлам до 260 символов.
Будучи переменной, вы думаете, мы могли бы изменить это. Нет, мы не должны. Это все равно что выдернуть нитку из свитера. Как только одна системная переменная изменяется, другие системные переменные и зависимые от них компоненты начинают распадаться.
Настройка Windows 10 на обработку длинных путей к файлам
Если вы знаете, что будете часто использовать длинные пути к файлам и длинные имена файлов, вам будет проще заставить Windows работать. Нет смысла использовать PowerShell для выполнения работы каждый день.
Есть два способа сделать это. Один предназначен для пользователей Windows 10 Home, а другой — для пользователей Windows 10 Pro или Enterprise. Эти методы могут работать для Windows 8.1 или более ранней версии, но мы не можем гарантировать это.
Параметры для Windows 10 Home
Всегда делайте резервную копию вашего реестра, прежде чем вносить какие-либо изменения. Узнайте все, что вам нужно знать об этом, в нашем окончательном руководстве по резервному копированию и восстановлению реестра Windows.
Открыв редактор реестра и сделав резервную копию, перейдите в папку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem и найдите ключ LongPathsEnabled.
Дважды щелкните LongPathsEnabled. Убедитесь, что в поле Значение данные: номер 1 указан. Нажмите OK, чтобы подтвердить изменения.
Выйдите из редактора реестра, и теперь вы сможете работать с безумными длинными путями к файлам.
Параметры для Windows 10 Pro или Enterprise
Чтобы позволить Windows 10 Pro или Enterprise использовать длинные пути к файлам, мы будем использовать редактор локальной групповой политики. Это инструмент, который позволяет нам устанавливать политики в отношении работы Windows на компьютере и на уровне пользователей.
После открытия редактора групповой политики перейдите к Конфигурация компьютера → Административные шаблоны → Система → Файловая система. Там вы увидите политику включения длинных путей Win32.
Дважды щелкните по нему, чтобы изменить параметр политики. Измените его с «Отключено» на «Включено», затем нажмите кнопку «ОК», чтобы зафиксировать изменение.
Политика может не вступить в силу сразу. Вы можете принудительно обновить групповую политику.
Как временно исправить проблему с файлами?
Легкое Исправление
Если вам повезет, вы получите ошибку и точно знаете, какое имя файла вызывает проблему. Или, по крайней мере, где найти файл. Может быть, у вас есть имя файла, которое выглядит примерно так:
Понятно, кто в этом случае виновник. Найдите файл в проводнике Windows или в проводнике, как он называется в Windows 10, нажмите один раз на него, нажмите F2, чтобы переименовать его, и измените это глупое имя файла на более разумное. Задача решена.
Менее простые исправления
Не всегда легко решить эту проблему. Иногда вы не можете изменить имена файлов или каталогов по любой причине.
Следующие решения помогут вам. Их несложно сделать.
Перемещение, удаление или копирование файлов или каталогов с помощью PowerShell
Иногда вы получаете сообщение об ошибке при попытке переместить, удалить или скопировать каталоги, где количество символов для пути к файлу превышает 260.
Обратите внимание, что слова каталог и папка являются взаимозаменяемыми. Мы будем использовать «каталог» в будущем. Следующие командлеты PowerShell также можно использовать для файлов.
Возможно, путь к файлу выглядит примерно так:
Этот путь к файлу составляет 280 символов. Поэтому мы не можем скопировать каталог оттуда куда-либо еще с помощью обычного метода копирования-вставки. Мы получаем ошибку Destination Path Too Long.
Давайте предположим, что по какой-то причине мы не можем переименовать каталоги, в которые вложен файл. Что мы делаем?
Когда откроется PowerShell, вы окажетесь в корне своего пользовательского каталога. Продолжайте, предполагая, что C:Usersguymc — ваш пользовательский каталог.
Вы увидите быстрое изменение текущего каталога на C:UsersguymcDocuments. Это хорошо. Мы работаем ближе к каталогам, которые облегчат жизнь.
Копирование каталога с использованием Copy-Item
Мы хотим скопировать каталог This и его содержимое в ThatNewFolder. Давайте используем команду PowerShell Copy-Item с параметрами -Destination и -Recurse.
-Destination сообщает PowerShell, где мы хотим, чтобы копия находилась. -Recurse говорит PowerShell скопировать все элементы внутри к месту назначения. Копирование оставляет оригиналы там, где они есть, и делает все новые в месте назначения.
Переместить каталог с помощью Move-Item
Допустим, мы хотим переместить каталог This, а также все каталоги и файлы в нем, в ThatNewFolder. Перемещение не оставляет оригинал на месте.
Мы можем использовать команду PowerShell Move-Item с параметрами -Path и -Destination. -Path определяет элемент, который мы хотим переместить, и -Destination сообщает PowerShell, где мы хотим его получить.
Команда поместит это в ThatNewFolder. Он также будет перемещать все, что находится внутри этого каталога. Move-Item может использоваться для перемещения файлов или каталогов, и он работает независимо от пути к файлу или длины имени файла.
Удалить каталог с помощью Remove-Item
Если мы хотим удалить этот каталог и все в нем, мы используем команду Remove-Item.
Командлет Remove-Item обладает некоторой встроенной безопасностью, которая затрудняет удаление каталога с содержимым внутри него. В нашем примере мы знаем, что хотим удалить все, поэтому мы будем использовать параметры -Recurse, чтобы заставить его удалять все внутри, и -Force, чтобы он делал это, не спрашивая нас, уверены ли мы в каждом элементе внутри.
Имейте в виду! Восстановить что-либо удаленное таким образом было бы чрезвычайно сложно.
Вы можете снова использовать команду dir, чтобы убедиться, что она пропала.
Вот и все
Существуют и другие способы обхода длинных имен файлов и путей к файлам, но то, что мы здесь рассмотрели, — это самые простые и эффективные методы.
Источник
Не секрет, что проводник Windows, как и большинство других Windows-приложений, включая PowerShell, не умеют работать с объектами файловой системы с глубокой вложенностью папок, длина пути к которым превышает 260 символов. Причем это ограничение существует только на уровне приложений, а сама файловая система NTFS поддерживает пути к файлам вплоть до 32767 символов.
Данное ограничение наложено библиотекой Win32 API, а которой максимальная длина пути составляет 260 символов (MAX_PATH=260). В общем случае путь формируется из следующих элементов: [C:]+[путь_из_256_символов]+[<NUL>], причем максимальная длина одного каталога/файла в NTFS — 255 символов в Unicode. При использовании юникодных функций API, возможно использовать путь до 32767 символов. Благодаря этому многие сторонние программы (те же популярные файловые менеджеры, например FAR и Total Commander) без каких-либо трудностей обрабатывает файлы/папки, длина пути к которым превышает 260 символов.
Совет. Обойти это ограничение Win32 API и работать с длинными именами файлов можно за счет использования UNC-формата пути, указывая абсолютный путь к файлу с использованием префикса extended-length path \?. Например, так \?C:SomeLongPathLongNameFile.txt
Это ограничение также не действует при сетевом доступе пользователей к файлам по протоколу SMB (за счет этого каталожные структуры с длинными путями нередкость именно на файловых серверах с пользовательскими данными). Администратор, обслуживающий данный сервер не может через стандартный интерфейс проводника Windows Explorer управлять (удалять/перемещать) файлы с длинными путями. При попытке создать/скопировать файл в такой каталог, появляется ошибка:
Destination Path Too Long. The file name (s) would be too long for the destination folder. You can shorten the file name and try again, or try a location that has a shorten path
Другие программы/диалоговые окна могут сообщать о наличии ограничения по своему.
Согласитесь забавно, что за окном 2014 год, а мы до сих пор говорим об ограничении в 260 символов на максимальную длину пути в Windows… Но похоже в ближайшее время никаких кардинальных изменений не предвидится, и даже в совсем свежей Windows 10 Technical Preview это ограничение все еще существует.
В этой статье мы покажем, как в Windows можно работать с файлами, путь к которым превышает 260 символов. В данном кейсе наша задача – удалить каталог, содержащий файлы с большой длиной пути.
При попытке удалить такой каталог из проводника появляется ошибка:
The file name(s) would be too long for the destination folder. You can shorten the file name and try again, or try a location that has a shorten path.
Powershell также не умеет корректно обрабатывать каталоги и файлы с большими путями, превышающими 260 символов. При попытке удалить каталог с такими файлами (C:InstallMS SQL 2012 Express Edition 64 bitverylongpath) появляется ошибка:
Remove-Item .verylongpath -Recurse
Remove-Item : The specified path, file name, or both are too long. The fully qualified file name must be less than 260
characters, and the directory name must be less than 248 characters.
At line:1 char:1
+ Remove-Item .verylongpath -Recurse
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : WriteError: (C:InstallMS S...itverylongpath:String) [Remove-Item], PathTooLongExcepti
on
+ FullyQualifiedErrorId : RemoveItemIOError,Microsoft.PowerShell.Commands.RemoveItemCommand
Самый простой вариант (он, собственно, и предлагается в окне с ошибкой) – сократить название родительских папок, уменьшив общую длину пути (но применимо не всегда).
Другой вариант – создать символическую ссылку на часть пути, укоротив тем самым общую длину пути:
mklink /d c:installlink “C:InstallMS SQL 2012 Express Edition 64 bitverylongpath”
Далее файловые операции проводить с каталогом, на который назначена символьная ссылка.
Еще один вариант, напоминающий работу с символьной ссылкой — сопоставить проблемную папку виртуальному диску (в нашем примере X: ), тем самым также сократив длину пути:
Subst X: “C:InstallMS SQL 2012 Express Edition 64 bitverylongpath”
Теперь можно работать с данными на диске X:, пути к файлам в котором не будут превышать лимит. После окончания работы можно удалить виртуальный диск:
Subst X: /d
Но лично мне больше всего для задачи удаления данных в таких ситуациях нравится возможности robocopy.exe, которая поддерживает работу с длинными путями.
С помощью опции /MIR, утилита robocopy может создать полную копию (зеркало) исходного каталога в целевом. И, если исходная папка пустая, все данные в целевой папке также очищаются. Создадим пустую папку C:Installtest и с помощью аргумента /MIR выполним копирование содержимое тестовой папки в целевую (если имя папки содержит пробелы или кириллические символы, путь нужно взять в кавычки).
robocopy /MIR C:Installtest "C:InstallMS SQL 2012 Express Edition 64 bitverylongpath"
После выполнения команды содержимое каталога C:InstallMS SQL 2012 Express Edition 64 bitverylongpath очищается (заменятся содержимым пустого каталога).
Итак, сегодня мы показали несколько простых трюков, которые можно использовать при работе с папками на файловых серверах, содержащих папки, длина пути к которым превышает лимит 260 символов.