Почему Windows слишком долго копирует эту папку?

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

Эй, Как-Выродок!

Итак, на днях я реорганизовывал некоторые файлы на своем компьютере, создавая папки и тому подобное. Затем, когда я перемещал некоторые файлы в папку, я получаю сообщение о том, что полученный путь к папке будет слишком длинным. Я был сбит с толку. Я знаю, что каждая ОС, поскольку DOS поддерживает длинные имена файлов, но Windows утверждает, что путь слишком длинный? Почему это происходит?

Sincerly,

Мистер Дезорганизован

Проблема, с которой вы сталкиваетесь, заключается в неудачном пересечении двух систем, которое в подобных случаях приводит к ошибке. Чтобы точно понять, откуда возникла ошибка, нам нужно изучить историю длинных имен файлов (LFN) и то, как Windows взаимодействует с ними, прежде чем углубляться в решения..

Длинные имена файлов были введены с помощью базовой архитектуры MS-DOS в Windows 95. Новая система LFN допускает имена файлов и каталогов длиной до 255 символов. Это было долгожданное расширение предыдущей системы имен файлов, обычно называемой 8.3 именованием файлов, потому что имя было ограничено восемью символами и трехзначным расширением, но также известно как Короткое имя файла (SFN). Как вы можете себе представить, тогда еще было много приложений на базе DOS, и было больше, чем несколько головных болей, пытавшихся заставить более новые LFN и устаревшие SFN хорошо играть друг с другом. Если вы когда-либо сталкивались со старой дискетой или компакт-диском со странно обрезанными файлами (например, abcdef ~ 1.txt), то это имя файла было вырезано некоторыми устаревшими приложениями, использующими SFN, из более длинного и неподдерживаемого LFN (например, abcdefghijk). текст).

Однако мы далеки от середины 1990-х годов, и вся вещь с длинным именем файла (по большей части) решительно сглажена. Если вы работаете с версией Windows за последние 10 лет, вы, скорее всего, никогда не столкнетесь с конфликтом длины имени файла, как мы привыкли сталкиваться в DOS / Windows 95 дней. Тем не менее, мы все еще сталкиваемся с ошибками, как вы обнаружили с вашим проектом очистки диска. Но почему? Если система длинных имен файлов Windows поддерживает папки и имена файлов длиной до 255 символов на компонент, с какой стеной вы столкнетесь? Мы не можем винить NTFS (файловую систему, которую использует подавляющее большинство современных компьютеров с Windows), поскольку NTFS будет поддерживать цепочку папок и имен файлов до общей длины пути 32 767 символов. Это намного превышает типичную структуру каталогов, которая понадобится большинству пользователей.

Там, где все это разваливается, стоит искусственное ограничение, которое накладывает Windows на систему LFN / NTFS: переменная MAX_PATH. Переменная MAX_PATH указывает, что полная структура каталогов в Windows не может превышать 260 символов, включая букву диска, двоеточие, обратную косую черту и нулевую обратную связь в конце. Таким образом, у вас есть только потенциальный реальный MAX_PATH из 256 символов, например. C: \ ваш-256-символьный-путь \.

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

Теперь вы можете думать: «А-а-а! Мы просто изменим переменную MAX_PATH и решим проблему! »Увы, все не так просто. Мало того, что переменная MAX_PATH по существу жестко запрограммирована в Windows, но даже если вы прошли через огромные хлопоты по ее изменению, вы в конечном итоге сломали бы столько, что это того не стоило бы. Слишком много приложений ожидают, что переменная пути будет такой, какой Windows давно указала. Мы не можем просто изменить его, не создав огромный беспорядок.

Где это тебя оставляет? Ну, самое простое решение - просто отредактировать данные пути. Например, если у вас есть тонна сохраненных статей, где приложение / расширение, которое вы использовали для сохранения их из Интернета, создали каталог, в котором был полный заголовок статьи + заголовок статьи, а затем само имя файла было полным заголовком. статьи + ведущий статьи, было бы действительно просто поразить или превысить MAX_PATH с помощью одного сохранения. Редактирование этих огромных заголовков папок и статей до более разумного размера - это простой способ решения проблемы..

Если у вас огромное количество файлов с длинным путем и вы не хотите редактировать их все (или если вы хотите удалять тонны старых каталогов, которые слишком длинные для Windows, чтобы иметь дело с ними, когда они ограничены переменной MAX_PATH), есть обход командной строки. Несмотря на то, что Windows ограничена переменной MAX_PATH, инженеры Windows поняли, что могут возникнуть ситуации, когда пользователям придется иметь дело с более длинными путями. Таким образом, в Windows API есть функция для работы с очень длинными путями..

Чтобы воспользоваться этим API и использовать инструменты командной строки для громоздких имен папок / файлов, вам просто нужно добавить имя каталога с несколькими дополнительными символами. Например, если у вас была огромная структура каталогов, которую вы хотели удалить (но при попытке ее получения произошла ошибка из-за длины пути), вы можете изменить команду с:

rmdir c: \ documents \ some-реально-супер-супер-длинное-имя-папки-схемы \

чтобы:

rmdir \\? \ c: \ documents \ some-реально-супер-супер-длинная-папка-name-схема \

Ключ является добавлением \\? \ часть перед началом пути к файлу; Это указывает Windows игнорировать ограничения, налагаемые переменной MAX_PATH, и взаимодействовать с только что указанным путем, который указан / понят непосредственно базовой файловой системой (которая может явно поддерживать более длинный путь). Как всегда, соблюдайте осторожность в командной строке, чтобы избежать случайного удаления файлов или каталогов, которые вы намеревались оставить нетронутыми.

Если наш обзор этой проблемы вызвал у вас любопытство, обязательно покопайтесь в этой статье из библиотеки Microsoft Developer Network, Naming Files, Paths и Namespaces, чтобы узнать больше о том, что происходит внутри..

Есть актуальный технический вопрос? Пришлите нам электронное письмо на [email protected], и мы постараемся ответить на него..