Создание коротких имен файлов должно быть отключено
Обновлено: 21.11.2024
В части 1 я объяснил основы коротких имен NTFS 8.3 и типичные проблемы, которые они могут вызвать, в основном, когда создание коротких имен было отключено или когда короткое имя не сохраняется при копировании файла и на новую копию ссылаются по ее первоначальному короткому имени.
Хорошо, а как отключить короткие имена? В этой статье TechNet рассматриваются значения параметра реестра «NtfsDisable8dot3NameCreation», который управляет поведением коротких имен. В старые времена, как в Windows XP и 2000, это значение по умолчанию было равно 0, что означает, что создание коротких имен не было отключено, поэтому оно было включено (что по умолчанию используется для новых установок, и по сей день, когда исходный установочный носитель Microsoft используется). В те дни единственным допустимым значением реестра было 1, что означало, что создание коротких имен было отключено на всех локальных томах, и для вступления в силу требовалась перезагрузка. В более поздних операционных системах были введены дополнительные значения для выполнения настроек для каждого тома (2) или для всех томов, кроме системного диска (3), а начиная с Vista перезагрузка не требуется, чтобы изменения вступили в силу.
Отключение коротких имен стало довольно распространенным явлением, так как Microsoft рекомендует сделать это в руководстве по безопасности, которое можно найти здесь. Есть также некоторые свидетельства того, что операции с файлами в папках, содержащих большое количество файлов с одинаковыми именами, могут значительно замедляться за счет создания коротких имен, поскольку ОС должна определять уникальные имена для каждого вновь созданного файла/папки.
Кроме того, команда «format» принимает необязательный аргумент /S: для включения или отключения коротких имен, и теперь по умолчанию отключено, поэтому любая ОС Windows, установленная в разделе, отформатированном вручную, например. через ADK/AIK короткие имена будут отключены. Я видел это в системах, созданных с помощью SCCM 2012, что затем вызывало проблемы с программным обеспечением, использующим appinit_dlls.
Чтобы проверить, отключены ли короткие имена для данного тома, запустите в командной строке от имени администратора следующую команду:
который вернет что-то вроде следующего, если создание короткого имени отключено:
Конечно, вы также можете создать новый файл с пробелом в имени (не забывая использовать кавычки вокруг имени файла), а затем запустить для него «dir /x», чтобы увидеть, создано ли короткое имя или нет. Преимущество этого подхода в том, что он не требует прав администратора.
Тогда для его включения достаточно запустить следующее:
однако любой файл или папка, созданные, когда создание коротких имен было отключено, по-прежнему не будут иметь короткого имени, поскольку они создаются только при первоначальном создании файла/папки, а не при последующем доступе к файлу, даже если создание коротких имен впоследствии было включено. .
Не все потеряно, так как мы можем добавить короткие имена для элементов, которые отсутствуют, снова используя команду fsutil, например:
Этот подход также можно использовать для «исправления» коротких имен, если они неверны, как, например, в моем примере robocopy в части 1. Обратите внимание, что если вы переключаете два коротких имени для двух файлов/папок, как в приведенном выше Например, вам нужно будет использовать временное короткое имя для одного из них, так как короткие имена должны быть уникальными для каждой папки в любое время:
Обратите внимание, что в приведенном выше примере я использовал временное короткое имя «SHORTY», которое не включает символ «~», поскольку короткие имена на самом деле не требуют его, просто алгоритм Microsoft, используемый для создания коротких имен, использует Это. Таким образом, теоретически вы можете работать с коротким именем «SHORTY», но только в том случае, если нет существующих ссылок на ожидаемое короткое имя «PROGRA~1» в приведенном выше примере, например в реестре.
Описанное выше хорошо работает для небольшого количества файлов/папок, таких как элементы, которые должны работать в старом добром значении реестра appinit_dlls, но для крупномасштабного исправления отсутствующих или неправильных коротких имен было бы немного утомительно сделать это вручную. Поэтому я написал утилиту, которая скопирует короткие имена из существующих файлов/папок и применит их к копии этих файлов/папок в новом месте. Идея состоит в том, что вы использовали robocopy или подобное (выборочное) копирование файлов в новое место, но, как описано в части 1, это, скорее всего, испортит короткие имена, так что программы, такие как Office, могут больше не работать.
Итак, если мы рекурсивно скопировали, скажем, «c:\program files (x86)» в d:\, запустите следующее, чтобы применить те же самые короткие имена из c: в d:
Обратите внимание на использование последовательности «\\?\» для отключения синтаксического анализа пути, как описано здесь, чтобы разрешить использование длинных имен файлов, до 32 КБ символов, вместо того, чтобы достигать обычного ограничения MAX_PATH (260 символов). Это необязательно, но хорошая идея, если ее поддерживают утилиты.
Вы также можете указать -v, чтобы получить подробный вывод о том, что происходит, и -c, чтобы продолжить в случае возникновения ошибок. Его следует запускать от имени администратора.
Он доступен здесь, вы используете его на свой страх и риск, так как он совершенно необязателен, и для него требуются распространяемые файлы Visual C++ 2013, которые доступны здесь.
Обычно администраторы отключают создание коротких имен файлов в NTFS. Я свободно признаю, что рекомендовал это в прошлом. Я был не прав?
Фон
NTFS относительно спокойно относится к именам файлов. Они могут быть довольно длинными (255 символов) и могут содержать «странные» символы (разрешены почти все символы UNICODE). Сегодня это считается само собой разумеющимся, но когда создавалась NTFS, многие приложения делали предположения о длине имен файлов и допустимых в них символах. Это были либо старые, либо плохо написанные приложения, но тем не менее операционная система должна была их поддерживать.
По этой лучшей из всех причин, обратной совместимости, NTFS обладает интересной возможностью: она может хранить несколько имен в файле. На практике он сохраняет одно имя файла, если это имя допустимо как для DOS, так и для Win32. Однако, если «настоящее» (Win32) имя файла слишком экзотично для строгого правила 8.3 DOS, вместе с ним сохраняется и сокращенная версия. Всякий раз, когда имя файла или каталога каким-либо образом изменяется, короткое имя должно быть получено из него и записано на диск. Вполне логично, что многие стараются избегать этой трудоемкой операции в файловой системе. Правда?
Под обложками
В NTFS все является файлом. Даже основная таблица файлов (MFT), ее продвинутый внук таблицы размещения файлов MSDOS (FAT). MFT состоит из файловых записей размером 1 КБ каждая. Записи файлов, в свою очередь, содержат стандартные свойства файлов, такие как дата/время, атрибуты, имена и так далее. Даже данные файла сохраняются в записи файла, если их достаточно мало, чтобы поместиться в то, что осталось от 1 КБ после того, как стандартные поля были записаны.
Как все это соотносится с утверждением, вынесенным в заголовок статьи?
Запись файла представляет собой плотно упакованную структуру. Во время создания файла различные поля, хранящиеся в этой структуре, должны быть скомпилированы в памяти и в любом случае записаны на диск. Во время переименования необходимо заменить хотя бы длинное имя файла. Для этого требуется как минимум один дисковый ввод-вывод. Увеличится ли объем данных, записанных во время этого единственного ввода-вывода, на 12 байт (длина имени файла 8.3), просто не имеет значения.
Хотя создание имен 8.3 не может снизить производительность диска, некоторые могут возразить, что ЦП по-прежнему требует дополнительной работы. В конце концов, короткое имя файла должно быть получено из длинного имени. Это, безусловно, операция, выполняемая процессором. Нужно сократить имя и преобразовать его в верхний регистр. Однако это настолько простая операция, что ее влияние на производительность просто невозможно измерить.
Недостающие части?!
Мои рассуждения выше убедительно доказывают, что дополнительное создание коротких имен файлов совсем не вредит производительности. Но некоторые части головоломки все еще отсутствуют.
Файловая система должна убедиться, что результирующее короткое имя уникально. Чтобы гарантировать уникальность полученного имени, оно должно сканировать все остальные элементы в текущем каталоге. Звучит как дорогостоящая операция, но это не так, по крайней мере, если каждая запись каталога имеет только одно имя. Благодаря организации записей каталогов в B+-деревьях они остаются отсортированными при минимизации дисковых операций ввода-вывода для поиска имен. Деревья B+ очень эффективны, но они также одномерны: для сортировки коротких и длинных имен потребуются два дерева, а в NTFS используется только одно. Это создает дополнительные дисковые операции ввода-вывода при создании коротких имен из длинных.
Поиск в файловой системе — это вторая причина, по которой дополнительное создание имен 8.3 может повлиять на производительность. Функции Win32 API FindFirstFile/FindNextFile широко используются приложениями. Опять же, деревья B+ могут значительно ускорить поиск, но при использовании двух разных пространств имен требуются дополнительные запросы к каталогу.
Без диспетчера кеша влияние коротких имен файлов на количество дисковых операций ввода-вывода и, следовательно, на производительность системы, вероятно, было бы значительным. Но важно иметь в виду, что Windows использует эффективное дисковое кэширование, которое значительно сокращает количество извлечений кластеров с физического диска. MFT, безусловно, стоит кэшировать.
Заключение
Единственное, что действительно влияет на производительность системы, — это выборка данных с диска. В своем анализе я обнаружил случаи, когда создание и обслуживание коротких имен файлов приводит к дополнительным операциям ввода-вывода на жестком диске. Однако эти эффекты смягчаются механизмами кэширования операционной системы.
Выигрыш в производительности от отключения создания имен 8.3, вероятно, невелик.Не думаю, что стоит ломать обратную совместимость. Как всегда, фактические цифры могут сильно различаться в зависимости от рабочей нагрузки, аппаратного обеспечения и других факторов.
Отказ от ответственности
Эта статья содержит теоретический анализ. Я не проводил практических испытаний в этом вопросе.
Ссылки
На многих веб-сайтах описывается, как отключить создание коротких имен файлов 8.3, установив следующее значение реестра:
В статье 130694 базы знаний говорится, что сохранение коротких и длинных имен может отрицательно сказаться на производительности NTFS. Но это применимо только к Windows NT 3.1 и 3.5 и остается относительно расплывчатым.
Обновить
Включил в анализ деревья B+ и перефразировал заключение.
Об авторе
Хельге Кляйн (бывшая CTP, MVP и vExpert) работала консультантом и разработчиком, прежде чем основать компанию uberAgent. Хельге применил свои обширные знания в проектах по ИТ-инфраструктуре и разработал продукт для управления профилями пользователей, преемник которого теперь доступен как Citrix Profile Management. Хельге является автором популярных инструментов Delprof2 и SetACL. Он выступал на Citrix Synergy, BriForum, E2EVC, Splunk.conf и многих других мероприятиях. Хельге очень активна в ИТ-сообществе и является соучредителем сообщества виртуализации NRW (VCNRW).
В этой статье представлены способы обхода проблемы, из-за которой появляется стоп-ошибка 00000019, когда NTFS создает имя в формате 8.3 для файла с длинным именем.
Применимо к: Windows Server 2003
Исходный номер базы знаний: 948289
Симптомы
На компьютере под управлением Windows Server 2003 вы можете получить сообщение об ошибке, похожее на следующее:
СТОП: 0x00000019 (параметр1, параметр2, параметр3, параметр4)
BAD_POOL_HEADER
- Параметры этого сообщения об ошибке Stop могут различаться в зависимости от конфигурации компьютера и типа проблемы.
- Не все стоп-ошибки 0x00000019 вызваны этой проблемой.
Причина
Эта проблема возникает из-за того, что память пула неожиданно повреждена. Эта проблема возникает, когда файловая система NTFS создает имя в формате имени 8.3 для файла с длинным именем.
Временное решение
Чтобы обойти эту проблему, отключите создание имени 8.3. Для этого воспользуйтесь одним из следующих способов.
Способ 1
Выполните следующую команду в командной строке:
Перезагрузите компьютер.
Метод 2
Этот раздел, метод или задача содержат инструкции по изменению реестра. Однако при неправильном изменении реестра могут возникнуть серьезные проблемы. Поэтому убедитесь, что вы внимательно выполните следующие действия. Для дополнительной защиты создайте резервную копию реестра перед его изменением. Затем вы можете восстановить реестр, если возникнет проблема. Дополнительные сведения о резервном копировании и восстановлении реестра см. в разделе Резервное копирование и восстановление реестра в Windows.
Нажмите "Пуск", выберите "Выполнить", введите regedit и нажмите "ОК".
Найдите и щелкните подраздел реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem .
Щелкните правой кнопкой мыши NtfsDisable8dot3NameCreation и выберите Изменить.
В поле "Значение" введите 1 и нажмите "ОК".
Значение по умолчанию – 0.
Выйти из редактора реестра.
Чтобы это изменение реестра вступило в силу, перезагрузите компьютер.
Статус
Microsoft подтвердила, что это проблема.
Подробнее
Не рекомендуется размещать этот раздел реестра на серверах, если только клиент не отправил файл дампа памяти в Microsoft для анализа и не была определена основная причина.
Читайте также: