Копирование файлов с длинными именами. Вот что это даёт
На одном из проектов довелось мне использовать модуль для 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\
Длинный у нас получился заголовок получился, но он указывает на суть проблемы, которая будет здесь описана. Недавно я столкнулся с не очень хорошей ситуацией. Сортируя на жёстком диске и очищая его от ненужного, я обнаружил, что один из файлов не удаляется, а появляется ошибка следующего содержания: «Файловая система не поддерживает такие длинные имена исходных файлов. Попробуйте перенести файл в папку с меньшей длиной пути или укажите более короткое имя файла и повторите попытку».
Я не только не мог удалить файл, но еще и изменить имя на более короткое имя тоже не удалось. Для многих это показалось бы тупиком, ведь получается, что файл не удаляем.На самом деле проблема решается очень просто и быстро, и сейчас я опишу два метода её решения, а каким пользоваться решать только вам.
Что делать, если слишком длинный путь к источнику, как удалить такой файл?
При наличии файла, который не удаляется из-за длинного имени, решить проблему можно несколькими вариантами. Например, файл вложен в несколько каталогов, допустим, пять или даже десять папок, которые имеют названия по 10-20 знаков, то это и может быть причиной не удаления файла. Дело в том, что Windows не поддерживает любые файлы, в названиях которых больше 260 символов. Если этот предел превышен, то появится ошибка, которую я показал выше. Количество папок, имеющие свои названия и само имя файла в сумме должны давать менее 260 символов. В системе также есть одна особенность – при превышении этого ограничения мы всё-таки можем переименовывать папки. А это значит, что необходимо переименовать все папки на короткое имя, например, буква или цифра.
Такая проблема может появиться не только из-за того, что вы дали такое длинное название. У меня это произошло тогда, когда я решил загрузить себе файлы сайты с сервера и кое-что сделать. Так как файлы уже были не нужны, я удалил весь каталог с файлами сайта, но как оказалось он содержал файл с очень длинным именем, плюс названия папок и это не дало мне всё это удалить.
Метод второй поможет, если с первым не удалось. Дело в том, что не все папки, ведущие к файлу с длинным именем, могут переименовываться и будет вылетать всё так же ошибка файловой системы. Тогда вы можете создать виртуальный диск, используя любую из вложенных папок, ведущих к не удаляемому файлу. Сейчас я покажу, как это сделать.
Открываем командную строку. Для этого нажимаем сочетание Win+R и вводим команду cmd . Можно нажать правой кнопкой мыши по меню Пуск (Либо сочетание клавиш Win+X) и выбрать там командную строку.
Теперь вы пишите такую команду, которая сделает для нас виртуальный диск:
Нужно выбрать такую букву диска, которая не занята другими. Системный раздел обычно указывается буков C, а второй раздел, как D или E, тогда выбираем любую другую.
Путь к папке нужно указывать от диска. Если у вас это вызывает сложность, то откройте ту папку, которая будет выступать в качестве виртуального диска и в проводнике вверху скопируйте путь до неё.
У меня эта команда выглядит следующим образом:
Когда мы зайдем в Мой компьютер, то там вы должны увидеть диск, с той буквой, которую мы ей присвоили из командной строки. Таким образом, путь к файлу сократиться практически в два раза, а это значит, что общая длинна символов может составлять менее 260 знаков. Теперь вы можете попробовать избавиться от неудаляемого.
Для того, чтобы виртуальный диск удалить нужно ввести команду:
| subst БукваДиска /d |
Используем Total Commander
В интернете я обнаружил метод, который позволяет удалить не удаляемые файлы при помощи . Конечно, минус тут в том, что придётся устанавливать дополнительный софт на компьютер, а это не все захотят делать. В любом случае оставлю этот способ здесь, вдруг кто захочет воспользоваться.
Скачиваем и устанавливаем программу. Идём во вкладку «Файл» щелкаем по разделу «Изменить атрибуты» . Появляется окошко, где убираем галки со всех атрибутов. Если вверху не стоит галочка напротив пункта «Обрабатывать содержимое каталогов» — выбираем. Теперь из этой же программы пробуем удалить файл с длинным именем.
Используем архиватор 7-Zip
Для этого дела нам понадобится архиватора 7-Zip. Нажимаем правой кнопкой мыши по начальному каталогу и направляем мышь на раздел «7-Zip» и выбираем пункт «Добавить к архиву» .
Появляется окно, в котором вам нужно отметить только одну галочку «Удалять файлы после сжатия» . Потом нажимаете ОК.
На рабочем столе создаётся архив всего этого добра, а папки с длинным файлом просто удаляются. Сам же архив вы можете удалить без проблем.
Вот такие способы по исправлению ошибки не удаляемого файла мы рассмотрели. Может быть у вас есть еще варианты, как можно это сделать?
Вредная операционная система 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. По мере поступления новых фактов и результатов экспериментов пост будет обновляться.Спасибо за внимание!