Hey How-To Geek!
So the other day, I was reorganizing some files on my computer, creating folders, that kind of stuff. Then, when I was moving some files into a folder, I get a message, stating that the resulting folder path would be too long. I was confused. I know that every single OS since DOS supports Long Filenames, yet Windows claims that the path is too long? Why does this happen?
Sincerly,
Mr. Disorganized
Проблема, с которой вы сталкиваетесь, - неудачное пересечение двух систем, которые в таких случаях приводят к ошибке. Чтобы точно понять, откуда возникает ошибка, нам нужно вникнуть в историю длинных имен файлов (LFN) и как Windows взаимодействует с ними, прежде чем мы углубимся в решения.
Длинные имена файлов были представлены через базовую архитектуру MS-DOS в Windows 95. Новая система LFN допускала имена файлов и каталогов до 255 символов. Это было долгожданное расширение предыдущей системы имен файлов, обычно называемой 8.3 filenaming, поскольку имя было ограничено восемью символами и трехзначным расширением, но также известным как Short Filename (SFN). Как вы можете себе представить, в то время было еще много приложений на основе DOS, и было несколько головных болей, пытающихся заставить новые LFN и устаревшие SFN играть хорошо друг с другом. Если вы когда-либо сталкивались с более старой дискеткой или компакт-диском с нечетно усеченными файлами на нем (например, abcdef ~ 1.txt), то имя файла было сокращено некоторым устаревшим приложением SFN с более длинным и неподдерживаемым LFN (например, abcdefghijk. текст).
Тем не менее, мы прошли долгий путь с середины 1990-х годов, и вся длинная страница Filename (по большей части) прочно сглажена. Если вы используете версию Windows за последние 10 лет, вы, вероятно, даже не столкнетесь с конфликтом длины имени файла, как мы привыкли работать в DOS / Windows 95 дней. Тем не менее, мы все еще сталкиваемся с икотой, как вы обнаружили с помощью проекта очистки диска. Но почему? Если система Windows Long Filename поддерживает имена папок и файлов длиной до 255 символов на один компонент, на какой стене вы работаете? Мы не можем винить NTFS (файловую систему, которую используют большинство современных машин Windows), поскольку NTFS будет поддерживать цепочку папок и имен файлов до общей длины пути 32 767 символов. Это намного превышает типичную структуру каталогов, которая потребуется большинству пользователей.
Где все это разваливается - это искусственное ограничение стеков Windows поверх системы LFN / NTFS: переменная MAX_PATH. Переменная MAX_PATH указывает, что полная структура каталогов в Windows не может превышать 260 общих символов, включая букву диска, двоеточие, обратную косую черту и нулевой люфт в конце. Таким образом, у вас есть только реальный MAX_PATH 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:documentssome-really-super-long-folder-name-scheme
чтобы:
rmdir \?c:documentssome-really-super-long-folder-name-scheme
Ключ является добавлением
?
до начала пути к файлу; это предписывает Windows игнорировать ограничения, налагаемые переменной MAX_PATH, и взаимодействовать с указанным вами способом, который предоставляется или понимается непосредственно базовой файловой системой (которая может четко поддерживать более длинный путь).Как всегда, будьте осторожны в командной строке, чтобы избежать случайного удаления файлов или каталогов, которые вы намерены оставить без изменений.
Если в нашем обзоре этой проблемы вам любопытно, обязательно ознакомьтесь с этой статьей из библиотеки разработчиков Microsoft Developer Network, «Именование файлов», «Пути» и «Пространства имен», чтобы получить дополнительную информацию о том, что происходит под капотом.
У вас есть неотложный технический вопрос? Выстрелите нам электронное письмо по адресу [email protected], и мы сделаем все возможное, чтобы ответить на него.
