Длинные имена файлов windows 2012

Картинка с сайта: habr.com

Думаю, вам, как и мне, не раз приходилось видеть пути вида \!!! Важное\____Новое____\!!! Не удалять!!!\Приказ №98819-649-Б от 30 февраля 1985г. о назначении Козлова Ивана Александровича временно исполняющим обязанности руководителя направления по сопровождению корпоративных VIP-клиентов и организации деловых встреч в кулуарах.doc.

И зачастую открыть такой документ в Windows сходу не получится. Кто-то практикует workaround в виде мапирования дисков, кто-то использует файловые менеджеры, умеющие работать с длинными путями: Far Manager, Total Commander и им подобные. А еще многие с грустью наблюдали, как созданный ими PS-скрипт, в который было вложено немало труда и который в тестовом окружении работал на ура, в боевой среде беспомощно жаловался на непосильную задачу: 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.
Как оказалось, 260 символов хватит «не только лишь всем». Если вам интересно выйти за границы дозволенного — прошу под кат.

Вот лишь некоторые из печальных последствий ограничения длины файлового пути:

• на сервере есть папка, например, D:\Data\Shared\Accounting, которая расшарена по SMB и монтируется пользователям как сетевой диск S; пользователи создают файлы, которые не смогут прочитать админы/скрипты при локальном доступе с сервера, т.к. абсолютный путь получается длиннее сетевого;
• ошибки синхронизации перемещаемых профилей;
• проблемы с восстановлением из теневых копий;
• при переносе данных из других систем, в которых менее жёсткие ограничения к длине пути, в новом окружении часть из них станет недоступной без танцев с бубном;
• неверные данные при подсчете размеров и количества файлов в папках;
• etc…

Немного отклоняясь от темы, замечу, что для DFS Replication рассматриваемая в статье проблема не страшна и файлы с длинными именами успешно путешествуют с сервера на сервер (если, конечно, в остальном вы всё сделали правильно).

Еще хотелось бы обратить внимание на очень полезную и не раз меня выручавшую утилиту robocopy. Ей тоже не страшны длинные пути, да и умеет она многое. Поэтому если задача сводится к копированию/переносу файловых данных, можно остановиться на ней. Если нужно пошаманить со списками контроля доступа в файловой системе (DACL), посмотрите в сторону subinacl. Несмотря на солидный возраст, отлично себя показала на Windows 2012 R2. Тут рассмотрены способы применения.

Мне же было интересно научить работать с длинными путями PowerShell. С ним почти как в бородатом анекдоте про Ивана-Царевича и Василису Прекрасную.

Быстрый способ

Перейти на

Linux и не париться

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

Учитывая, что в большинстве компаний много, мягко говоря, не свежих версий операционных систем, способ этот быстрый только для написания на бумаге, если, конечно, вы не из тех счастливчиков, у которых мало legacy-систем и царят Windows 10/2016/2019.

Долгий способ

Тут сразу оговоримся, что изменения не затронут поведение проводника Windows, а дадут возможность использовать длинные пути в командлетах PowerShell, таких как Get-Item, Get-ChildItem, Remove-Item и др.

Для начала обновим PowerShell. Делается на раз-два-три.

1. Обновляем .NET Framework до версии не ниже 4.6 (вообще, PowerShell 5.1 установится и на 4.5, но, судя по жалобам на форумах, некоторые PS-командлеты при такой конфигурации могут работать неправильно). Операционная система должна быть не ниже Windows 7 SP1/2008 R2. Актуальную версию загрузить можно здесь, дополнительную информацию почитать тут.
2. Скачиваем и устанавливаем Windows Management Framework 5.1
3. Перезагружаем машину.

Трудолюбивые могут сделать описанные выше шаги вручную, ленивые — с помощью SCCM, политик, скриптов и

эникеев

других средств автоматизации.

Текущую версию PowerShell можно узнать из переменной $PSVersionTable. После обновления должно быть примерно так:

Картинка с сайта: habr.com

Теперь при использовании командлетов Get-ChildItem и ему подобных вместо привычного Path будем использовать LiteralPath.

Формат путей при этом будет немного другим:

Get-ChildItem -LiteralPath "\\?\C:\Folder"
Get-ChildItem -LiteralPath "\\?\UNC\ServerName\Share"
Get-ChildItem -LiteralPath "\\?\UNC\192.168.0.10\Share"

Для удобства преобразования путей из привычного формата в формат LiteralPath можно использовать вот такую функцию:

Function ConvertTo-LiteralPath {
Param([parameter(Mandatory=$true, Position=0)][String]$Path)
    If ($Path.Substring(0,2) -eq "\\") {Return ("\\?\UNC" + $Path.Remove(0,1))}
    Else {Return "\\?\$Path"}
}

Обратите внимание, что при задании параметра LiteralPath нельзя использовать подстановочные символы (*, ? и т.д.).

Помимо параметра LiteralPath, в обновленной версии PowerShell командлет Get-ChildItem получил параметр Depth, с помощью которого можно задавать глубину вложенности для рекурсивного поиска, я пару раз его использовал и остался доволен.

Теперь можно не бояться, что ваш PS-скрипт собьется с долгого тернистого пути и не разглядит далекие файлы. Меня, например, очень выручил этот подход при написании скрипта для сбрасывания атрибута «временный» у файлов в DFSR-папках. Но это уже другая история, о которой я постараюсь рассказать в другой статье.
UPD 06.07.2019: Обещанная статья
От вас же жду интересных комментариев и предлагаю пройти опрос.
UPD 23.07.2020: Если командлет Get-ChildItem выдает ошибку «путь содержит недопустимые знаки», обновите .NET Framework до актуальной версии (за уточнение спасибо mordaden).

Полезные ссылки:
docs.microsoft.com/ru-ru/dotnet/api/microsoft.powershell.commands.contentcommandbase.literalpath?view=powershellsdk-1.1.0
docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-5.1
stackoverflow.com/questions/46308030/handling-path-too-long-exception-with-new-psdrive/46309524
luisabreu.wordpress.com/2013/02/15/theliteralpath-parameter

Актуальна ли для вас проблема длинных путей?

Проголосовали 178 пользователей. Воздержались 27 пользователей.

Не секрет, что проводник 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:\SomeLongPath\LongNameFile.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

Картинка с сайта: winitpro.ru

Другие программы/диалоговые окна могут сообщать о наличии ограничения по своему.

Согласитесь забавно, что за окном 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.

Картинка с сайта: winitpro.ru

Powershell также не умеет корректно обрабатывать каталоги и файлы с большими путями, превышающими 260 символов. При попытке удалить каталог с такими файлами (C:\Install\MS SQL 2012 Express Edition 64 bit\verylongpath) появляется ошибка:

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:\Install\MS S...it\verylongpath:String) [Remove-Item], PathTooLongExcepti
on
+ FullyQualifiedErrorId : RemoveItemIOError,Microsoft.PowerShell.Commands.RemoveItemCommand

Картинка с сайта: winitpro.ru

Самый простой вариант (он, собственно, и предлагается в окне с ошибкой) – сократить название родительских папок, уменьшив общую длину пути (но применимо не всегда).

Другой вариант – создать символическую ссылку на часть пути, укоротив тем самым общую длину пути:

mklink /d c:\install\link “C:\Install\MS SQL 2012 Express Edition 64 bit\verylongpath”

Далее файловые операции проводить с каталогом, на который назначена символьная ссылка.

Еще один вариант, напоминающий работу с символьной ссылкой — сопоставить проблемную папку виртуальному диску (в нашем примере X: ), тем самым также сократив длину пути:

Subst X: “C:\Install\MS SQL 2012 Express Edition 64 bit\verylongpath”

Теперь можно работать с данными на диске X:, пути к файлам в котором не будут превышать лимит. После окончания работы можно удалить виртуальный диск:

Subst X: /d

Но лично мне больше всего для задачи удаления данных в таких ситуациях нравится возможности robocopy.exe, которая поддерживает работу с длинными путями.

С помощью опции /MIR, утилита robocopy может создать полную копию (зеркало) исходного каталога в целевом. И, если исходная папка пустая, все данные в целевой папке также очищаются. Создадим пустую папку C:\Install\test и с помощью аргумента /MIR выполним копирование содержимое тестовой папки в целевую (если имя папки содержит пробелы или кириллические символы, путь нужно взять в кавычки).

robocopy /MIR C:\Install\test "C:\Install\MS SQL 2012 Express Edition 64 bit\verylongpath"

Картинка с сайта: winitpro.ru

Картинка с сайта: winitpro.ru

После выполнения команды содержимое каталога C:\Install\MS SQL 2012 Express Edition 64 bit\verylongpath очищается (заменятся содержимым пустого каталога).

Итак, сегодня мы показали несколько простых трюков, которые можно использовать при работе с папками на файловых серверах, содержащих папки, длина пути к которым превышает лимит 260 символов.