Вредная операционная система Windows не даёт Вам удалить файл и кричит, что у него «Слишком длинный путь к источнику»? В этой статье я расскажу Вам как легко и просто, без каких-либо программ, победить эту напасть сократив имя файла.
Слишком длинный путь к источнику — почему?
Сразу хочу объяснить, почему появляется такое системное предупреждение и не удаётся произвести с файлом (папкой) элементарные действия копирования или удаления…
В самом уведомлении написан ответ на этот вопрос — файловая система Windows не поддерживает (не понимает) имена исходных файлов длиннее 255 символов.
Но имя файла или папки у Вас короткое, например, «Фото из отпуска»? Дело в том, что «глупая» система воспринимает весь путь к файлу как его имя. Если Ваш файл или папка лежат где-то слишком глубоко в файловом менеджере, то его имя для неё будет выглядеть примерно так…
Вот и собираются символы имени в банду из более 255 штук.
Как удалить неудаляемый файл или папку в таком случае? Очень просто — нужно сократить имя файла (пути) методом переименования вложенных друг в друга папок.
Как удалить файл с длинным именем
Покажу на своём примере как удалить файл с длинным именем у которого, как пишет система, слишком длинный путь к источнику.
Вчера решил почистить свой компьютер от старых резервных копий сайта, а они не захотели удаляться. Как Вы догадались — появилось предупреждение о слишком длинном пути к источнику…
Начиная с самой первой папки в этом длинном пути — переименовал несколько штук…
…и повторил попытку избавиться от файла с теперь более коротким именем — он благополучно отправился в страну удалённых файлов.
Естественно, что новое имя файла (папки) должно состоять из одного символа или цифры, как у меня в примере.
Вот так просто решается проблема удаления файлов или папок с длинным именем. Это не единственный метод конечно. Можно специальными программами удалять или через реестр — я лишь показал ручной способ. У кого-то он займёт минуту всего, а у кого-то и полчаса — решать Вам, как сократить имя файла и слишком длинный путь к источнику.
До новых полезных советов и интересных компьютерных программ.
Многим пользователям ПК под управлением ОС Windows, не говоря о разработчиках, знакомы проблемы при работе с длинными (более 260 символов, MAX_PATH) путями файлов или каталогов.
В данной статье рассматриваются способы избавления от этого пережитка при разработке приложений на различных платформах (WinApi, .Net Framework, .Net Core) и активации нативной поддержки длинных путей в Windows 10 (Anniversary Update).
Приложения Win API
В приложениях, которые используют Win API для работы с файлами, рецепт избавления от ограничения MAX_PATH был известен с незапамятных времён – необходимо было использовать Unicode версию функции с окончанием «W» для работы с директорией или файлом и начинать путь с префикса \\?\. Это давало возможность использовать пути длинной до 32767 символов.В Windows 10 (1607) поведение функций для работы с файлами изменилось: появилась возможность отключить проверку ограничений MAX_PATH на уровне системы.
Это коснулось следующих функций:
Для работы с каталогами:
CreateDirectoryW, CreateDirectoryExW, GetCurrentDirectoryW, RemoveDirectoryW, SetCurrentDirectoryW. И для работы с файлами:
CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.
Это избавляет от необходимости использовать префикса \\?\ и потенциально даёт шанс приложениям, работающим напрямую или косвенно через Win API, получить поддержку длинных путей без необходимости их пересборки. Как активировать эту возможность описано в конце статьи.
.Net Framework
Хотя.Net Framework и использует Win API для работы с файлами - предыдущее изменение не принесло бы результата, т.к. в код BCL встроены предварительные проверки на допустимость длинны имён каталогов и файлов, и до вызова функций Win API дело даже не доходило, выдавая известное исключение. По многочисленным просьбам сообщества (более 4500 на UserVoice) в версии 4.6.2 из кода BCL вырезали проверки ограничения длинны пути, отдав это на откуп операционной и файловой системам!Вот что это даёт:
- При использовании префикса “\\?\” мы можем работать с длинными путями как в Win API, Directory.CreateDirectory("\\\\?\\" + long_dir_name);
- Если активировать нативную поддержку длинных имен файлов Windows 10 (1607), то даже не потребуется использовать префикс!
- Использовать.Net Framework 4.6.2 как цель при сборке приложения.
- Использовать конфигурационный файл, например, если приложение уже было собрано под.Net 4.0:
.Net Core
Тут поддержку длинных путей анонсировали ещё в ноябре 2015 года. Видимо сказалось Open Source природа проекта и отсутствие строгой необходимости обеспечения обратной совместимости.Как включить:
Всё работает из коробки. В отличие от реализации в.Net Framework – тут нет необходимости в добавлении префикса “\\?\” – он добавляется автоматически при необходимости.
Вот можно посмотреть пример.
Как включить поддержку длинных путей в Windows 10 (1607)
Эта возможность по умолчанию отключена. Это объясняется тем, что данная функция является экспериментальной, и имеется необходимость дорабатывать различные подсистемы и приложения для полной поддержки.Включить встроенную поддержку длинных путей можно создав или изменив следующий параметр системного реестра: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem Параметр LongPathsEnabled (Тип: REG_DWORD) 1 – соответствует значению включено.
Или через групповые политики (Win+R\gpedit.msc) Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. Оно же в локализованном варианте: Конфигурация компьютера > Административные шаблоны > Система > Файловая система > Включить длинные пути Win32.
Далее источники расходятся во мнении относительно манифеста (или я неправильно понял, но на данный момент проверить не имею возможности). Например, в документации MSDN написано, что манифест можно использовать в качестве альтернативного способа активации поддержки длинных путей в отдельных приложениях, а в блоге MSDN указано, что это является вторым обязательным шагом после активации в политиках.
Но они сходятся в формате задания данной опции:
С CMD, к сожалению, это не сработает, на данный момент, из-за особенностей работы с путями, а в PowerShell должно всё заработать.
P.S.
На этом мой небольшой пятничный пост заканчивается, оставив за рамками вопросы полноты реализации поддержки длинных путей в Windows 10 (1607), или работоспособность при использовании различных комбинаций редакций Windows, файловых систем и API. По мере поступления новых фактов и результатов экспериментов пост будет обновляться.Спасибо за внимание!
Не секрет, что проводник Windows, как и большинство других Windows-приложений, включая PowerShell, не умеют работать с объектами файловой системы с глубокой вложенностью папок, длина пути к которым превышает 260 символов . Причем это ограничение существует только на уровне приложений, а сама файловая система NTFS поддерживает пути к файлам вплоть до 32767 символов.
Данное ограничение наложено библиотекой Win32 API
, а которой максимальная длина пути составляет 260 символов (MAX_PATH=260
). В общем случае путь формируется из следующих элементов: +[путь_из_256_символов]+[
Совет . Обойти это ограничение 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
Другие программы/диалоговые окна могут сообщать о наличии ограничения по своему.
Согласитесь забавно, что за окном 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:\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) , PathTooLongExcepti
on
+ FullyQualifiedErrorId: RemoveItemIOError,Microsoft.PowerShell.Commands.RemoveItemCommand 
Самый простой вариант (он, собственно, и предлагается в окне с ошибкой) – сократить название родительских папок, уменьшив общую длину пути (но применимо не всегда).
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"
После выполнения команды содержимое каталога C:\Install\MS SQL 2012 Express Edition 64 bit\verylongpath очищается (заменятся содержимым пустого каталога).
Итак, сегодня мы показали несколько простых трюков, которые можно использовать при работе с папками на файловых серверах, содержащих папки, длина пути к которым превышает лимит 260 символов.
На одном из проектов довелось мне использовать модуль для Drupal - clientside validation. И не то чтобы модуль плохой, наоборот полностью выполняет свой функционал, а именно проверяет форму на стороне клиента. Но файлы модуля имеют довольно длинные названия, и вот из-за одного из таких файлов, наш git перестал работать адекватно. Поскольку записать информацию в эту папку уже не мог по причине следующей ошибки:
Не удается скопировать файл /папку. Слишком длинное имя / целевой путь конечного файла
Или тоже но на английском:
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 shorter path.
Проведя маленькое расследование оказалось, что максимальная длина пути которая поддерживается Windows 7 - 260 символов. А поскольку все проекты храняться у меня в папке C:\Users\\Documents\xampp\htdocs\git\ - то потенциально под угрозой оказались все проекты.
Варианты решения
Вариантов решения видел 2:
1. Перенести xampp в голову диска
2. Создать алиас для этого пути (Например диск с именем H)
Второй вариант показался более простым, ведь для xampp пути не поменяются, а gitом будем заходить в папки через созданный алиас. Ну еще для правильной работы IDE придется изменить путь проектам.
И так, для того чтобы Windows подставляла вместо Вашего длинного пути, имя диска - выполняем через cmd команду:
Subst H: C:\Users\\Documents\xampp\htdocs\git\
Значение слова неудачный
Обзор Samsung Galaxy A7 (2017): не боится воды и экономии Стоит ли покупать samsung a7
Делаем бэкап прошивки на андроиде
Как настроить файл подкачки?
Установка режима совместимости в Windows