Особое место на диске, где хранятся имена файлов, называется

Обновлено: 05.07.2024

В этой статье объясняются различия между таблицей размещения файлов (FAT), высокопроизводительной файловой системой (HPFS) и файловой системой NT (NTFS) в Windows NT, а также их преимущества и недостатки.

Применимо к: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер базы знаний: 100108

HPFS поддерживается только в Windows NT версий 3.1, 3.5 и 3.51. Windows NT 4.0 не поддерживает и не может получить доступ к разделам HPFS. Кроме того, поддержка файловой системы FAT32 стала доступна в Windows 98/Windows 95 OSR2 и Windows 2000.

Обзор FAT

FAT — самая простая из файловых систем, поддерживаемых Windows NT. Файловая система FAT характеризуется таблицей размещения файлов (FAT), которая на самом деле является таблицей, находящейся в самом «верху» тома. Для защиты тома хранятся две копии FAT на случай повреждения одной из них. Кроме того, таблицы FAT и корневой каталог должны храниться в фиксированном месте, чтобы загрузочные файлы системы могли быть правильно расположены.

Диск, отформатированный с помощью FAT, размещается в кластерах, размер которых определяется размером тома. При создании файла в каталоге создается запись и устанавливается первый номер кластера, содержащего данные. Эта запись в таблице FAT либо указывает, что это последний кластер файла, либо указывает на следующий кластер.

Обновление таблицы FAT очень важно и требует много времени. Если таблица FAT регулярно не обновляется, это может привести к потере данных. Это отнимает много времени, поскольку головки чтения диска должны перемещаться на нулевую логическую дорожку диска каждый раз при обновлении таблицы FAT.

Структура каталогов FAT не организована, и файлы размещаются в первом открытом месте на диске. Кроме того, FAT поддерживает только атрибуты файлов только для чтения, скрытые, системные и архивные.

Соглашение об именах FAT

FAT использует традиционное соглашение об именах файлов 8.3, и все имена файлов должны создаваться с использованием набора символов ASCII. Имя файла или каталога может содержать до восьми символов, затем разделитель точки (.) и расширение до трех символов. Имя должно начинаться с буквы или цифры и может содержать любые символы, кроме следующих:

При использовании любого из этих символов могут возникнуть непредвиденные результаты. Имя не может содержать пробелов.

Следующие имена зарезервированы:

CON, AUX, COM1, COM2, COM3, COM4, ​​LPT1, LPT2, LPT3, PRN, NUL

Все символы будут преобразованы в верхний регистр.

Преимущества FAT

Невозможно выполнить восстановление в Windows NT ни в одной из поддерживаемых файловых систем. Утилиты восстановления пытаются получить прямой доступ к оборудованию, что невозможно сделать в Windows NT. Однако, если файл находился в разделе FAT и система перезагружается в MS-DOS, файл можно восстановить. Файловая система FAT лучше всего подходит для дисков и/или разделов размером менее 200 МБ, потому что FAT начинается с очень небольших накладных расходов. Для дальнейшего обсуждения преимуществ FAT см. следующее:

Windows NT Server "Концепции и руководство по планированию", глава 5, раздел "Выбор файловой системы"

Комплект ресурсов Windows NT Workstation 4.0, глава 18, "Выбор файловой системы"

Комплект ресурсов Windows NT Server 4.0 "Руководство по ресурсам", глава 3, раздел "Какую файловую систему использовать на каких томах"

Недостатки FAT

При использовании дисков или разделов размером более 200 МБ желательно не использовать файловую систему FAT. Это связано с тем, что по мере увеличения размера тома производительность с FAT быстро снижается. Невозможно установить разрешения для файлов, которые являются разделами FAT.

Размер разделов FAT ограничен 4 гигабайтами (ГБ) в Windows NT и 2 ГБ в MS-DOS.

Для дальнейшего обсуждения других недостатков FAT см. следующее:

Windows NT Server "Концепции и руководство по планированию", глава 5, раздел "Выбор файловой системы"

Комплект ресурсов Windows NT Workstation 4.0, глава 18, "Выбор файловой системы"

Комплект ресурсов Microsoft Windows NT Server 4.0 "Руководство по ресурсам", глава 3, раздел "Какую файловую систему использовать на каких томах"

Обзор HPFS

Файловая система HPFS была впервые представлена ​​в OS/2 1.2, чтобы обеспечить более широкий доступ к большим жестким дискам, которые тогда появлялись на рынке. Кроме того, для новой файловой системы было необходимо расширить систему именования, организацию и безопасность для растущих потребностей рынка сетевых серверов. HPFS поддерживает организацию каталогов FAT, но добавляет автоматическую сортировку каталога на основе имен файлов. Имена файлов расширены до 254 двухбайтовых символов.HPFS также позволяет составлять файл из «данных» и специальных атрибутов, чтобы обеспечить повышенную гибкость с точки зрения поддержки других соглашений об именах и безопасности. Кроме того, единица распределения изменена с кластеров на физические секторы (512 байт), что сокращает потери дискового пространства.

В HPFS записи каталога содержат больше информации, чем в FAT. Помимо файла атрибутов, он включает информацию о дате и времени модификации, создания и доступа. Вместо того, чтобы указывать на первый кластер файла, записи каталога в HPFS указывают на FNODE. FNODE может содержать данные файла или указатели, которые могут указывать на данные файла или на другие структуры, которые в конечном итоге будут указывать на данные файла.

HPFS пытается разместить как можно больше файлов в смежных секторах. Это сделано для увеличения скорости при последовательной обработке файла.

Кроме того, HPFS включает несколько уникальных специальных объектов данных:

Суперблок

Суперблок расположен в логическом секторе 16 и содержит указатель на FNODE корневого каталога. Одна из самых больших опасностей использования HPFS заключается в том, что если суперблок потерян или поврежден из-за поврежденного сектора, то же самое произойдет и с содержимым раздела, даже если остальная часть диска в порядке. Восстановить данные на диске можно было бы, скопировав все на другой диск с исправным сектором 16 и перестроив суперблок. Однако это очень сложная задача.

Запасной блок

Запасной блок расположен в логическом секторе 17 и содержит таблицу «горячих исправлений» и блок запасного каталога. В HPFS при обнаружении поврежденного сектора запись «горячих исправлений» используется для логического указания на существующий исправный сектор вместо поврежденного сектора. Этот метод обработки ошибок записи называется оперативным исправлением.

Оперативное исправление – это метод, при котором в случае возникновения ошибки из-за поврежденного сектора файловая система перемещает информацию в другой сектор и помечает исходный сектор как неисправный. Все это делается прозрачно для любых приложений, выполняющих дисковый ввод-вывод (то есть приложение никогда не узнает о каких-либо проблемах с жестким диском). Использование файловой системы, поддерживающей оперативное исправление, устранит сообщения об ошибках, такие как FAT «Прервать, повторить попытку или сбой?» сообщение об ошибке, возникающее при обнаружении поврежденного сектора.

Версия HPFS, входящая в состав Windows NT, не поддерживает оперативное исправление.

Преимущества HPFS

HPFS лучше всего подходит для дисков емкостью 200–400 МБ. Дополнительные сведения о преимуществах HPFS см. в следующих материалах:

Windows NT Server "Концепции и руководство по планированию", глава 5, раздел "Выбор файловой системы"

Комплект ресурсов Windows NT Workstation 4.0, глава 18, "Выбор файловой системы"

Комплект ресурсов Windows NT Server 4.0 "Руководство по ресурсам", глава 3, раздел "Какую файловую систему использовать на каких томах"

Недостатки HPFS

Из-за накладных расходов, связанных с HPFS, это не очень эффективный выбор для тома менее примерно 200 МБ. Кроме того, при использовании томов размером более 400 МБ производительность может снизиться. Вы не можете установить безопасность на HPFS под Windows NT.

HPFS поддерживается только в Windows NT версий 3.1, 3.5 и 3.51. Windows NT 4.0 не может получить доступ к разделам HPFS.

Дополнительные недостатки HPFS см. в следующем:

Windows NT Server "Концепции и руководство по планированию", глава 5, раздел "Выбор файловой системы"

Комплект ресурсов Windows NT Workstation 4.0, глава 18, "Выбор файловой системы"

Комплект ресурсов Windows NT Server 4.0 "Руководство по ресурсам", глава 3, раздел "Какую файловую систему использовать на каких томах"

Обзор NTFS

С точки зрения пользователя, NTFS продолжает организовывать файлы в каталоги, которые, как и HPFS, сортируются. Однако, в отличие от FAT или HPFS, на диске нет «специальных» объектов и нет зависимости от базового оборудования, например секторов по 512 байт. Кроме того, на диске нет специальных мест, таких как таблицы FAT или суперблоки HPFS.

Цели NTFS – обеспечить:

Надежность, особенно желательная для высокопроизводительных систем и файловых серверов

Платформа для дополнительных функций

Поддержка требований POSIX

Снятие ограничений файловых систем FAT и HPFS

Надежность

Чтобы обеспечить надежность NTFS, были рассмотрены три основные области: возможность восстановления, устранение фатальных сбоев отдельных секторов и оперативное исправление.

NTFS — это восстанавливаемая файловая система, поскольку она отслеживает транзакции в файловой системе. Когда CHKDSK выполняется в FAT или HPFS, проверяется непротиворечивость указателей в таблицах каталогов, выделений и файлов.В NTFS ведется журнал транзакций для этих компонентов, так что CHKDSK нужно только откатить транзакции до последней точки фиксации, чтобы восстановить согласованность в файловой системе.

В FAT или HPFS, если произойдет сбой сектора, в котором расположен один из специальных объектов файловой системы, произойдет сбой одного сектора. NTFS избегает этого двумя способами: во-первых, не используя специальные объекты на диске и отслеживая и защищая все объекты, находящиеся на диске. Во-вторых, в NTFS хранится несколько копий (количество зависит от размера тома) основной таблицы файлов.

Подобно версиям HPFS для OS/2, NTFS поддерживает оперативное исправление.

Добавлена ​​функциональность

Одной из основных целей разработки Windows NT на всех уровнях является предоставление платформы, которую можно добавлять и использовать, и NTFS не является исключением. NTFS предоставляет богатую и гибкую платформу для использования другими файловыми системами. Кроме того, NTFS полностью поддерживает модель безопасности Windows NT и поддерживает несколько потоков данных. Файл данных больше не является единым потоком данных. Наконец, в NTFS пользователь может добавлять в файл свои собственные определяемые пользователем атрибуты.

Поддержка POSIX

NTFS является наиболее совместимой с POSIX.1 из поддерживаемых файловых систем, поскольку она поддерживает следующие требования POSIX.1:

В POSIX README.TXT, Readme.txt и readme.txt — это разные файлы.

Дополнительная отметка времени:

Дополнительная отметка времени указывает время последнего доступа к файлу.

Жесткая ссылка — это когда два файла с разными именами, которые могут находиться в разных каталогах, указывают на одни и те же данные.

Снять ограничения

Во-первых, NTFS значительно увеличила размер файлов и томов, так что теперь они могут достигать 2^64 байт (16 эксабайт или 18 446 744 073 709 551 616 байт). NTFS также вернулась к концепции кластеров FAT, чтобы избежать проблемы HPFS с фиксированным размером сектора. Это было сделано потому, что Windows NT — переносная операционная система, и в какой-то момент могут встретиться различные дисковые технологии. Следовательно, 512 байт на сектор рассматривались как имеющие большую вероятность того, что они не всегда подходят для распределения. Это было достигнуто за счет возможности определения кластера как кратного размера естественного распределения аппаратного обеспечения. Наконец, в NTFS все имена файлов основаны на Unicode, а имена файлов 8.3 сохраняются вместе с длинными именами файлов.

Преимущества NTFS

NTFS лучше всего подходит для томов размером около 400 МБ и более. Это связано с тем, что производительность не снижается в NTFS, как в FAT, при больших размерах томов.

Возможность восстановления, предусмотренная в NTFS, такова, что пользователю никогда не придется запускать какую-либо утилиту восстановления диска в разделе NTFS. Дополнительные преимущества NTFS см. в следующем:

Windows NT Server "Концепции и руководство по планированию", глава 5, раздел "Выбор файловой системы"

Комплект ресурсов Windows NT Workstation 4.0, глава 18, "Выбор файловой системы"

Комплект ресурсов Windows NT Server 4.0 "Руководство по ресурсам", глава 3, раздел "Какую файловую систему использовать на каких томах"

Недостатки NTFS

Не рекомендуется использовать NTFS на томе размером менее примерно 400 МБ из-за того, что NTFS занимает много места. Эти накладные расходы связаны с системными файлами NTFS, которые обычно занимают не менее 4 МБ дискового пространства в разделе размером 100 МБ.

В настоящее время в NTFS нет встроенного шифрования файлов. Поэтому кто-то может загрузиться под MS-DOS или другой операционной системой и использовать низкоуровневую утилиту редактирования диска для просмотра данных, хранящихся на томе NTFS.

Невозможно отформатировать дискету с файловой системой NTFS; Windows NT форматирует все гибкие диски в файловой системе FAT, потому что служебные данные, связанные с NTFS, не помещаются на дискету.

Для дальнейшего обсуждения недостатков NTFS см. следующее:

Windows NT Server "Концепции и руководство по планированию", глава 5, раздел "Выбор файловой системы"

Комплект ресурсов Windows NT Workstation 4.0, глава 18, "Выбор файловой системы"

Комплект ресурсов Windows NT Server 4.0 "Руководство по ресурсам", глава 3, раздел "Какую файловую систему использовать на каких томах"

Соглашения об именах NTFS

Имена файлов и каталогов могут содержать до 255 символов, включая любые расширения. Имена сохраняют регистр, но не чувствительны к регистру. NTFS не различает имена файлов по регистру. Имена могут содержать любые символы, кроме следующих:

В настоящее время из командной строки можно создавать имена файлов длиной не более 253 символов.

Основные аппаратные ограничения могут налагать дополнительные ограничения на размер раздела в любой файловой системе. В частности, загрузочный раздел может иметь размер только 7,8 ГБ, а размер таблицы разделов ограничен 2 ТБ.

Дополнительную информацию о поддерживаемых файловых системах для Windows NT см. в наборе ресурсов Windows NT.

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

Не уверен, что это правильный сайт стека, чтобы задать этот вопрос, но я нашел его наиболее "логичным".

У нас большой спор по поводу того, где в системе хранится имя файла. Один из нас думает, что имя файла хранится в метаданных файлов. Другие не согласны, мы думаем, что имя файла каким-то образом хранится в каталоге или файловой системе. Если это правильно, то как файловая система указывает от имени файла к правильному файлу и двоичным данным?

Он хранится с каким-то идентификатором или файловая система добавляет ссылку на точку на жестком диске, где находится файл?

Я потерялся? Я пытался найти это в Интернете, но не смог найти то, что искал.

Редактировать: я вижу, что некоторые из вас спрашивают, о какой файловой системе я говорю, но я спрашиваю это «в целом». Если некоторые файловые системы не хранят это в своей системе, значит имя файла должно храниться в метаданных? Где еще должно храниться имя файла?

В HopelessN00bFS имена файлов хранятся в облаке. Какую файловую систему вы имеете в виду? (Это важно.)

Вы продолжаете говорить «метаданные», как будто это какое-то отдельное место. Как вы думаете, где хранятся метаданные?

4 ответа 4

Судя по исходному и дополнительным вопросам, вы не понимаете, как работают файловые системы.

"Диск" - это не что иное, как очень-очень длинная строка нулей и единиц. Компьютер должен использовать стандартный метод управления этими нулями и единицами, называемый «файловой системой». На разных типах компьютеров существует множество различных типов файловых систем — FAT32, NTFS, EXTFS, ResierFS и так далее. Выбор файловой системы имеет решающее значение для связи между компьютером, обращающимся к диску, и нулями и единицами, хранящимися на диске. Если файловая система отформатирована как EXTFS, но компьютер по какой-то причине решает использовать ResierFS для управления диском, это приведет к полному повреждению данных.

Многие файловые системы на базе Unix, например EXTFS и ее производные, логически делят диск на несколько разделов. Один раздел - это «таблица inode». Эта область содержит «иноды». Каждый inode относится к определенному файлу и будет описывать, например, тип файла («обычный» файл, каталог, устройство, сокет и т. д.), владельца, разрешения и раздел(ы) « data" часть диска, где могут располагаться данные файла.

Затем будет область «данные». Для «обычного» файла здесь будет храниться содержимое файла. В случае каталога здесь хранится список имен файлов (по одному имени для каждого файла, содержащегося в этом каталоге) и индексные дескрипторы, на которые ссылается каждое из этих имен файлов.

Когда вы хотите найти файл, вы указываете его "путь". Компьютер начинает с корня пути ("/"), находит имя первого объекта в пути ("usr"), а затем

  • находит свой inode
  • замечает, что это каталог
  • получает имя следующего объекта на пути
  • находит этот объект в каталоге
  • повторить

пока, наконец, не будет найден объект, индексный дескриптор которого указывает "не каталог".

Один из нас думает, что имя файла хранится в метаданных файлов.

Нет, в большинстве классических файловых систем Unix нет. В FAT32 и NTFS понятия не имею.

Другие не согласны, мы думаем, что имя файла каким-то образом хранится в каталоге

Когда вы смотрите на жесткий диск в Unix, вы видите дерево именованных каталогов и файлов. Обычно вам не нужно заглядывать глубже, но становится полезно знать, что происходит внутри, если у вас произошел сбой диска и вам нужно попытаться спасти файлы. К сожалению, нет хорошего способа описать организацию диска от уровня файлов вниз, поэтому мне придется описать ее от аппаратного обеспечения вверх.

Unix делит диск на разделы. Каждый раздел представляет собой непрерывный диапазон блоков, который используется отдельно от любого другого раздела либо в качестве файловой системы, либо в качестве пространства подкачки. Первоначальные причины создания разделов были связаны с аварийным восстановлением в мире гораздо более медленных и подверженных ошибкам дисков; границы между ними уменьшают долю вашего диска, которая может стать недоступной или поврежденной из-за случайного плохого места на диске. В настоящее время более важно, чтобы разделы могли быть объявлены доступными только для чтения (предотвращая изменение важных системных файлов злоумышленником) или общими по сети с помощью различных средств, которые мы не будем здесь обсуждать.Раздел с наименьшим номером на диске часто рассматривается как загрузочный раздел, на который можно поместить загружаемое ядро.

В каждой файловой системе сопоставление имен с блоками осуществляется с помощью структуры, называемой i-узлом. Рядом с «дном» (блоками с наименьшими номерами) каждой файловой системы находится пул этих вещей (самые низкие используются для обслуживания и маркировки, которые мы не будем здесь описывать). Каждый i-узел описывает один файл. Блоки файловых данных (включая каталоги) располагаются над i-узлами (в блоках с более высокими номерами).

Каждый i-узел содержит список номеров дисковых блоков в файле, который он описывает. (На самом деле это полуправда, верно только для небольших файлов, но остальные детали здесь не важны.) Обратите внимание, что i-узел не содержит имени файла.

Имена файлов живут в структурах каталогов. Структура каталогов просто сопоставляет имена с номерами i-узлов. Вот почему в Unix файл может иметь несколько истинных имен (или жестких ссылок); это просто несколько записей каталога, которые указывают на один и тот же i-узел.

В самом простом случае вся ваша файловая система Unix находится всего в одном разделе диска. Хотя вы увидите такое расположение на некоторых небольших персональных Unix-системах, оно необычно. Более типичным является его распределение по нескольким разделам диска, возможно, на разных физических дисках. Так, например, в вашей системе может быть один небольшой раздел, на котором находится ядро, другой, немного большего размера, на котором находятся утилиты ОС, и еще один, на котором находятся домашние каталоги пользователей.

Единственный раздел, к которому у вас будет доступ сразу после загрузки системы, — это ваш корневой раздел, который (почти всегда) является тем, с которого вы загрузились. Он содержит корневой каталог файловой системы, верхний узел, от которого зависит все остальное.

Другие разделы в системе должны быть присоединены к этому корню, чтобы вся файловая система с несколькими разделами была доступна. Примерно в середине процесса загрузки ваш Unix сделает эти разделы без полномочий root доступными. Он смонтирует каждый из них в каталог корневого раздела.

Например, если у вас есть каталог Unix с именем /usr , вероятно, это точка подключения к разделу, содержащему множество программ, установленных вместе с Unix, но не требуемых при начальной загрузке.

Теперь мы можем посмотреть на файловую систему сверху вниз. Когда вы открываете файл (например, /home/esr/WWW/ldp/fundamentals.xml ), происходит следующее:

Ваше ядро ​​запускается в корне файловой системы Unix (в корневом разделе). Он ищет там каталог под названием «home». Обычно «дом» — это точка подключения к большому пользовательскому разделу в другом месте, поэтому он будет идти туда. В структуре каталогов верхнего уровня этого пользовательского раздела он будет искать запись с именем «esr» и извлекать номер i-узла. Он перейдет к этому i-узлу, заметит, что связанные с ним блоки файловых данных представляют собой структуру каталогов, и найдет «WWW». Извлекая этот i-узел, он перейдет в соответствующий подкаталог и найдет «ldp». Это приведет его к еще одному каталогу i-node. Открыв его, он найдет номер i-узла для «fundamentals.xml». Этот i-узел не является каталогом, а содержит список дисковых блоков, связанных с файлом.

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

Основные разрешения, которые могут быть связаны с файлом, — это «чтение» (разрешение на чтение данных из него), «запись» (разрешение на его изменение) и «выполнение» (разрешение на запуск его как программы). Каждый файл имеет три набора разрешений; один для пользователя-владельца, один для любого пользователя в группе-владельце и один для всех остальных. «Привилегии», которые вы получаете при входе в систему, — это просто возможность читать, писать и выполнять те файлы, для которых биты разрешений соответствуют вашему идентификатору пользователя или одной из групп, в которых вы состоите, или файлы, которые были сделаны доступными. миру.

Чтобы увидеть, как они могут взаимодействовать и как Unix их отображает, давайте посмотрим на некоторые списки файлов в гипотетической системе Unix. Вот один:

snark:~$ ls -l notes -rw-r--r-- 1 esr users 2993 17 июня 11:00 заметки

Это обычный файл данных. Листинг говорит нам, что он принадлежит пользователю «esr» и был создан с группой-владельцем «users». Вероятно, машина, на которой мы находимся, по умолчанию помещает каждого обычного пользователя в эту группу; другие группы, которые вы обычно видите на машинах с разделением времени, — это «персонал», «администратор» или «колесо» (по понятным причинам группы не очень важны на однопользовательских рабочих станциях или ПК). Ваш Unix может использовать другую группу по умолчанию, возможно, группу, названную в честь вашего идентификатора пользователя.

Строка «-rw-r--r--» представляет биты прав доступа к файлу.Самый первый тире — это позиция для бита каталога; он покажет «d», если файл был каталогом, или покажет «l», если файл был символической ссылкой. После этого первые три места — это разрешения пользователя, вторые три — групповые разрешения, а третье — разрешения для других (часто называемые «мировыми» разрешениями). В этом файле пользователь-владелец «esr» может читать или записывать файл, другие люди в группе «пользователи» могут его читать, и все остальные в мире могут его читать. Это довольно типичный набор разрешений для обычного файла данных.

Теперь давайте посмотрим на файл с очень разными разрешениями. Это файл GCC, компилятор GNU C.

snark:~$ ls -l /usr/bin/gcc -rwxr-xr-x 3 root bin 64796 21 марта 16:41 /usr/bin/gcc

Этот файл принадлежит пользователю с именем «root» и группе с именем «bin»; он может быть записан (изменен) только пользователем root, но прочитан или выполнен кем угодно. Это типичное владение и набор разрешений для предустановленной системной команды. Группа «bin» существует в некоторых Unix-системах для группировки системных команд (название — историческая реликвия, сокращение от «binary»). Вместо этого ваш Unix может использовать группу «root» (не совсем то же самое, что пользователь «root»!).

Пользователь root — это обычное имя для числового идентификатора пользователя 0, специальной привилегированной учетной записи, которая может переопределить все привилегии. Доступ с правами root полезен, но опасен; опечатка при входе в систему с правами root может стереть важные системные файлы, которые не может затронуть та же самая команда, выполненная из учетной записи обычного пользователя.

Поскольку корневая учетная запись очень мощная, доступ к ней следует очень тщательно охранять. Ваш корневой пароль — это самая важная часть информации о безопасности в вашей системе, и это то, что взломщики и злоумышленники, которые когда-либо придут к вам, будут пытаться получить его.

О паролях: не записывайте их и не выбирайте пароли, которые можно легко угадать, например, имя вашей девушки/друга/супруга. Это удивительно распространенная плохая практика, которая безмерно помогает взломщикам. В общем, не выбирайте слова в словаре; существуют программы, называемые взломщиками словарей, которые ищут вероятные пароли, просматривая списки слов с наиболее частыми вариантами. Хорошая техника — подобрать комбинацию, состоящую из слова, цифры и другого слова, например «shark6cider» или «jump3joy»; это сделает пространство поиска слишком большим для взломщика словарей. Однако не используйте эти примеры — взломщики могут ожидать этого после прочтения этого документа и добавления их в свои словари.

Теперь давайте рассмотрим третий случай:

snark:~$ ls -ld ~ drwxr-xr-x 89 пользователей esr 9216 27 июня 11:29 /home2/esr snark:~$

Этот файл является каталогом (обратите внимание на букву «d» в первом слоте разрешений). Мы видим, что его может написать только esr, а прочитать и выполнить кто угодно другой.

Разрешение на чтение дает вам возможность составить список каталогов, то есть просмотреть имена файлов и каталогов, которые в нем содержатся. Разрешение на запись дает вам возможность создавать и удалять файлы в каталоге. Если вы помните, что каталог включает в себя список имен содержащихся в нем файлов и подкаталогов, эти правила будут иметь смысл.

Разрешение на выполнение для каталога означает, что вы можете получить доступ к каталогу, чтобы открыть файлы и каталоги, расположенные ниже него. По сути, это дает вам разрешение на доступ к i-узлам в каталоге. Каталог с полностью отключенным выполнением был бы бесполезен.

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

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

Наконец, давайте посмотрим на разрешения самой программы входа в систему.

snark:~$ ls -l /bin/login -rwsr-xr-x 1 root bin 20164 17 апреля 12:57 /bin/login

У этого есть разрешения, которые мы ожидаем для системной команды, за исключением того, что "s", где должен быть бит владельца-исполнения. Это видимое проявление специального разрешения, называемого set-user-id или битом setuid .

Бит setuid обычно присваивается программам, которым необходимо предоставить обычным пользователям привилегии root, но контролируемым образом. Когда он установлен для исполняемой программы, вы получаете привилегии владельца этого файла программы, пока программа работает от вашего имени, независимо от того, совпадают ли они с вашими собственными.

Как и сама учетная запись root, программы setuid полезны, но опасны. Любой, кто может подорвать или изменить программу setuid, принадлежащую пользователю root, может использовать ее для создания оболочки с привилегиями root.По этой причине открытие файла для записи автоматически отключает бит setuid на большинстве Unix. Многие атаки на безопасность Unix пытаются использовать ошибки в программах setuid, чтобы разрушить их. Поэтому системные администраторы, заботящиеся о безопасности, очень внимательно относятся к этим программам и неохотно устанавливают новые.

При обсуждении разрешений выше мы упустили несколько важных деталей; а именно, как группа-владелец и разрешения назначаются при первом создании файла или каталога. Группа является проблемой, поскольку пользователи могут быть членами нескольких групп, но одна из них (указанная в записи пользователя /etc/passwd) является группой пользователя по умолчанию и обычно владеет файлами, созданными пользователем.

История с начальными битами разрешения немного сложнее. Программа, которая создает файл, обычно указывает разрешения, с которыми она должна начинаться. Но они будут изменены переменной в среде пользователя, называемой umask. Маска umask указывает, какие биты разрешений следует отключить при создании файла; наиболее распространенным значением и значением по умолчанию в большинстве систем является -------w- или 002, что отключает бит мировой записи. Для получения подробной информации см. документацию по команде umask на странице руководства вашей оболочки.

Начальная группа каталогов также немного сложна. В некоторых системах Unix новый каталог получает группу по умолчанию создавшего пользователя (это в соглашении System V); на других он получает группу владельцев родительского каталога, в котором он создан (это соглашение BSD). В некоторых современных системах Unix, включая Linux, последнее поведение можно выбрать, установив set-group-ID для каталога (chmod g+s).

Ранее намекали, что файловые системы могут быть хрупкими. Теперь мы знаем, что для того, чтобы получить доступ к файлу, вам нужно пройти через сколь угодно длинную цепочку ссылок на каталоги и i-узлы. Теперь предположим, что на вашем жестком диске появилось плохое место?

Если вам повезет, он уничтожит только некоторые данные файла. Если вам не повезет, это может повредить структуру каталогов или номер i-узла и оставить целое поддерево вашей системы в подвешенном состоянии или, что еще хуже, привести к поврежденной структуре, которая несколькими путями указывает на один и тот же блок диска или i- узел. Такие повреждения могут распространяться обычными операциями с файлами, уничтожая данные, которых не было в исходном плохом месте.

К счастью, такие непредвиденные обстоятельства стали редкостью, поскольку дисковое оборудование стало более надежным. Тем не менее, это означает, что ваш Unix будет периодически проверять целостность файловой системы, чтобы убедиться, что все в порядке. Современные Unix выполняют быструю проверку целостности каждого раздела во время загрузки, непосредственно перед его монтированием. Каждые несколько перезагрузок они будут проводить гораздо более тщательную проверку, которая занимает на несколько минут больше времени.

Если все это звучит так, как будто Unix ужасно сложна и подвержена сбоям, может быть приятно узнать, что эти проверки во время загрузки обычно выявляют и устраняют обычные проблемы до того, как они станут действительно катастрофическими. Другие операционные системы не имеют этих средств, что немного ускоряет загрузку, но может привести к гораздо более серьезным проблемам при попытке восстановления вручную (и это при условии, что у вас есть копия Norton Utilities или что-то еще).

Одной из тенденций в современных разработках Unix является журналирование файловых систем. Они организуют трафик на диск таким образом, что он гарантированно находится в согласованном состоянии, которое может быть восстановлено при резервном копировании системы. Это значительно ускорит проверку целостности во время загрузки.

Все файловые системы, поддерживаемые Windows, используют концепцию файлов и каталогов для доступа к данным, хранящимся на диске или устройстве. Разработчики Windows, работающие с Windows API для ввода-вывода файлов и устройств, должны понимать различные правила, соглашения и ограничения имен файлов и каталогов.

Доступ к данным можно получить с дисков, устройств и общих сетевых ресурсов с помощью API файлового ввода-вывода. Файлы и каталоги, наряду с пространствами имен, являются частью концепции пути, который представляет собой строковое представление того, где можно получить данные, независимо от того, получены ли они с диска, устройства или сетевого подключения для конкретной операции.

Некоторые файловые системы, такие как NTFS, поддерживают связанные файлы и каталоги, которые также следуют соглашениям и правилам именования файлов, как и обычные файлы или каталоги. Дополнительные сведения см. в разделах «Жесткие ссылки и соединения» и «Точки повторной обработки и операции с файлами».

Дополнительную информацию см. в следующих подразделах:

Чтобы узнать, как настроить Windows 10 для поддержки длинных путей к файлам, см. статью Ограничение максимальной длины пути.

Имена файлов и каталогов

Все файловые системы следуют одним и тем же общим соглашениям об именах для отдельных файлов: базовое имя файла и необязательное расширение, разделенные точкой. Однако каждая файловая система, такая как NTFS, CDFS, exFAT, UDFS, FAT и FAT32, может иметь определенные и отличающиеся правила формирования отдельных компонентов пути к каталогу или файлу.Обратите внимание, что каталог — это просто файл со специальным атрибутом, определяющим его как каталог, но в остальном он должен соответствовать тем же правилам именования, что и обычный файл. Поскольку термин каталог просто относится к особому типу файла в том, что касается файловой системы, в некоторых справочных материалах используется общий термин файл для охвата обеих концепций каталогов. и файлы данных как таковые. По этой причине, если не указано иное, любые правила или примеры именования или использования файла также должны применяться к каталогу. Термин путь относится к одному или нескольким каталогам, обратной косой черте и, возможно, имени тома. Дополнительные сведения см. в разделе «Пути».

Ограничения по количеству символов также могут различаться в зависимости от файловой системы и используемого формата префикса имени пути. Это еще более усложняется поддержкой механизмов обратной совместимости. Например, более старая файловая система MS-DOS FAT поддерживает не более 8 символов для основного имени файла и 3 символа для расширения, всего 12 символов, включая разделитель точек. Это обычно известно как имя файла 8.3. Файловые системы Windows FAT и NTFS не ограничены именами файлов версии 8.3, поскольку они имеют поддержку длинных имен файлов, но они по-прежнему поддерживают версию 8.3 длинных имен файлов.

Соглашения об именах

Следующие основные правила позволяют приложениям создавать и обрабатывать допустимые имена для файлов и каталогов независимо от файловой системы:

Используйте точку, чтобы отделить базовое имя файла от расширения в имени каталога или файла.

Используйте обратную косую черту (\) для разделения компонентов пути. Обратная косая черта отделяет имя файла от пути к нему и одно имя каталога от другого имени каталога в пути. Вы не можете использовать обратную косую черту в имени фактического файла или каталога, потому что это зарезервированный символ, который разделяет имена на компоненты.

При необходимости используйте обратную косую черту в имени тома, например, "C:\" в "C:\path\file" или "\\server\share" в "\\server\share\path". \file" для имен универсального соглашения об именах (UNC). Дополнительные сведения об именах UNC см. в разделе «Ограничение максимальной длины пути».

Не предполагайте чувствительность к регистру. Например, считайте имена OSCAR, Oscar и oscar одинаковыми, хотя некоторые файловые системы (например, POSIX-совместимая файловая система) могут считать их разными. Обратите внимание, что NTFS поддерживает семантику POSIX для учета регистра, но это не поведение по умолчанию. Дополнительные сведения см. в разделе CreateFile.

Обозначения томов (буквы дисков) также нечувствительны к регистру. Например, "D:\" и "d:\" относятся к одному и тому же тому.

Используйте любой символ текущей кодовой страницы для имени, включая символы Unicode и символы расширенного набора символов (128–255), за исключением следующих:

Следующие зарезервированные символы:

  • (больше)
  • : (двоеточие)
  • " (двойные кавычки)
  • / (косая черта)
  • \ (обратная косая черта)
  • | (вертикальная полоса или труба)
    • <ли>? (вопросительный знак)
  • * (звездочка)

Целое значение, равное нулю, иногда называемое символом NUL ASCII.

Символы, целочисленные представления которых находятся в диапазоне от 1 до 31, за исключением альтернативных потоков данных, где эти символы разрешены. Дополнительные сведения о файловых потоках см. в разделе Файловые потоки.

Любой другой символ, который не разрешен целевой файловой системой.

Используйте точку в качестве компонента каталога в пути для представления текущего каталога, например ".\temp.txt". Дополнительные сведения см. в разделе Пути.

Используйте две последовательные точки (..) в качестве компонента каталога в пути для представления родительского каталога текущего каталога, например "..\temp.txt". Дополнительные сведения см. в разделе Пути.

Не используйте следующие зарезервированные имена для имени файла:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, ​​COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 и LPT9. Также избегайте этих имен, за которыми сразу следует расширение; например, NUL.txt не рекомендуется. Дополнительные сведения см. в разделе Пространства имен.

Не заканчивайте имя файла или каталога пробелом или точкой. Хотя базовая файловая система может поддерживать такие имена, оболочка Windows и пользовательский интерфейс этого не делают. Однако допустимо указывать точку в качестве первого символа имени. Например, ".temp".

Короткие и длинные имена

Длинным именем файла считается любое имя файла, которое выходит за рамки короткого стиля именования MS-DOS (также называемого 8.3). Когда вы создаете длинное имя файла, Windows также может создать короткую форму имени 8.3, называемую псевдонимом 8.3 или коротким именем, и также сохранить ее на диске. Это 8.3 псевдонимы могут быть отключены по соображениям производительности либо для всей системы, либо для указанного тома, в зависимости от конкретной файловой системы.

Windows Server 2008, Windows Vista, Windows Server 2003 и Windows XP: псевдонимы 8.3 нельзя отключить для указанных томов до Windows 7 и Windows Server 2008 R2.

Во многих файловых системах имя файла будет содержать тильду (~) в каждом компоненте имени, которое слишком длинно для соответствия правилам именования 8.3.

Не все файловые системы следуют соглашению о замене тильды, и системы можно настроить таким образом, чтобы отключить создание псевдонима 8.3, даже если они обычно его поддерживают. Поэтому не думайте, что псевдоним 8.3 уже существует на диске.

Чтобы запросить имена файлов 8.3, длинные имена файлов или полный путь к файлу из системы, рассмотрите следующие варианты:

  • Чтобы получить форму длинного имени файла в формате 8.3, используйте функцию GetShortPathName.
  • Чтобы получить версию короткого имени с длинным именем файла, используйте функцию GetLongPathName.
  • Чтобы получить полный путь к файлу, используйте функцию GetFullPathName.

В более новых файловых системах, таких как NTFS, exFAT, UDFS и FAT32, Windows сохраняет длинные имена файлов на диске в кодировке Юникод, что означает, что исходное длинное имя файла всегда сохраняется. Это верно, даже если длинное имя файла содержит расширенные символы, независимо от кодовой страницы, которая активна во время операции чтения или записи с диска.

Файлы с длинными именами файлов можно копировать между разделами файловой системы NTFS и разделами файловой системы Windows FAT без потери информации об именах файлов. Это может быть не так для более старых файловых систем MS-DOS FAT и некоторых типов файловых систем CDFS (CD-ROM), в зависимости от фактического имени файла. В этом случае по возможности заменяется короткое имя файла.

Пути

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

Если компонент пути является именем файла, он должен быть последним компонентом.

Каждый компонент пути также будет ограничен максимальной длиной, указанной для конкретной файловой системы. В целом, эти правила делятся на две категории: короткие и длинные. Обратите внимание, что имена каталогов хранятся в файловой системе как файлы особого типа, но правила именования файлов также применяются к именам каталогов. Подводя итог, можно сказать, что путь — это просто строковое представление иерархии между всеми каталогами, существующими для определенного файла или имени каталога.

Полный и относительный пути

Для функций Windows API, управляющих файлами, имена файлов часто могут указываться относительно текущего каталога, а для некоторых API требуется полный путь. Имя файла относится к текущему каталогу, если оно не начинается с одного из следующих символов:

  • Имя UNC любого формата, которое всегда начинается с двух символов обратной косой черты ("\\"). Дополнительные сведения см. в следующем разделе.
  • Обозначение диска с обратной косой чертой, например "C:\" или "d:\".
  • Одна обратная косая черта, например, "\directory" или "\file.txt". Его также называют абсолютным путем.

Если имя файла начинается только с обозначения диска, но не с обратной косой черты после двоеточия, оно интерпретируется как относительный путь к текущему каталогу на диске с указанной буквой. Обратите внимание, что текущий каталог может быть или не быть корневым каталогом в зависимости от того, что он был установлен во время самой последней операции «изменить каталог» на этом диске. Ниже приведены примеры этого формата:

  • «C:tmp.txt» относится к файлу с именем «tmp.txt» в текущем каталоге на диске C.
  • "C:tempdir\tmp.txt" относится к файлу в подкаталоге текущего каталога на диске C.

Путь также считается относительным, если он содержит "двойные точки"; то есть два периода вместе в одном компоненте пути. Этот специальный спецификатор используется для обозначения каталога над текущим каталогом, также известного как «родительский каталог». Ниже приведены примеры этого формата:

  • "..\tmp.txt" указывает файл с именем tmp.txt, расположенный в родительском каталоге текущего каталога.
  • "..\..\tmp.txt" указывает файл, который находится на два каталога выше текущего каталога.
  • "..\tempdir\tmp.txt" указывает файл с именем tmp.txt, расположенный в каталоге с именем tempdir, который является равноправным каталогом для текущего каталога.

Относительные пути могут сочетать оба типа примеров, например "C.\tmp.txt".Это полезно, потому что, хотя система отслеживает текущий диск вместе с текущим каталогом этого диска, она также отслеживает текущие каталоги в каждой из разных букв диска (если в вашей системе их несколько), независимо от какое обозначение диска установлено в качестве текущего диска.

Ограничение максимальной длины пути

В выпусках Windows до Windows 10 версии 1607 максимальная длина пути — MAX_PATH, которая определяется как 260 символов. В более поздних версиях Windows для снятия ограничения требуется изменение раздела реестра или использование инструмента групповой политики. Полную информацию см. в разделе Ограничение максимальной длины пути.

Пространства имен

Существует две основные категории соглашений о пространствах имен, используемых в Windows API, обычно называемых пространствами имен NT и пространствами имен Win32. Пространство имен NT было разработано как пространство имен самого низкого уровня, в котором могут существовать другие подсистемы и пространства имен, включая подсистему Win32 и, соответственно, пространства имен Win32. POSIX — еще один пример подсистемы Windows, созданной на основе пространства имен NT. Ранние версии Windows также определяли несколько предопределенных или зарезервированных имен для определенных специальных устройств, таких как коммуникационные (последовательные и параллельные) порты и консоль дисплея по умолчанию, как часть того, что сейчас называется пространством имен устройств NT, и все еще поддерживаются в текущих версиях. Windows для обратной совместимости.

Пространства имен файлов Win32

В этом и следующем разделах кратко изложены префиксы и соглашения пространства имен Win32 с описанием их использования. Обратите внимание, что эти примеры предназначены для использования с функциями Windows API, и не все они обязательно работают с приложениями оболочки Windows, такими как проводник Windows. По этой причине существует более широкий диапазон возможных путей, чем обычно доступно из приложений оболочки Windows, и приложения Windows, которые используют это преимущество, могут быть разработаны с использованием этих соглашений о пространстве имен.

При файловом вводе-выводе префикс "\\?\" к строке пути указывает API-интерфейсам Windows отключить всю строку синтаксического анализа и отправить строку, следующую за ней, прямо в файловую систему. Например, если файловая система поддерживает большие пути и имена файлов, вы можете превысить ограничения MAX_PATH, которые в противном случае применяются API-интерфейсами Windows. Дополнительные сведения об обычном ограничении максимального пути см. в предыдущем разделе Ограничение максимальной длины пути.

Поскольку он отключает автоматическое расширение строки пути, префикс "\\?\" также позволяет использовать ".." и "." в именах путей, что может быть полезно, если вы пытаетесь выполнить операции с файлом с этими зарезервированными в противном случае спецификаторами относительного пути как части полного пути.

Многие, но не все API файлового ввода-вывода поддерживают "\\?\"; вы должны посмотреть справочную тему для каждого API, чтобы быть уверенным.

Обратите внимание, что следует использовать API Unicode, чтобы убедиться, что префикс "\\?\" позволяет превысить MAX_PATH

Пространства имен устройств Win32

Префикс "\\.\" будет обращаться к пространству имен устройств Win32, а не к пространству имен файлов Win32. Так осуществляется доступ к физическим дискам и томам напрямую, минуя файловую систему, если API поддерживает такой тип доступа. Таким образом вы можете получить доступ ко многим устройствам, кроме дисков (например, с помощью функций CreateFile и DefineDosDevice).

Например, если вы хотите открыть последовательный порт 1 системы, вы можете использовать "COM1" в вызове функции CreateFile. Это работает, потому что COM1–COM9 являются частью зарезервированных имен в пространстве имен NT, хотя использование префикса «\\.\» также будет работать с этими именами устройств. Для сравнения, если у вас установлена ​​плата последовательного расширения на 100 портов и вы хотите открыть COM56, вы не сможете открыть ее с помощью «COM56», поскольку для COM56 нет предопределенного пространства имен NT. Вам нужно будет открыть его с помощью "\\.\COM56", потому что "\\.\" переходит непосредственно к пространству имен устройства, не пытаясь найти предопределенный псевдоним.

Другим примером использования пространства имен устройств Win32 является использование функции CreateFile с "\\.\PhysicalDiskX" (где X – допустимое целочисленное значение) или " \\.\CdRomX". Это позволяет вам обращаться к этим устройствам напрямую, минуя файловую систему. Это работает, потому что эти имена устройств создаются системой по мере перечисления этих устройств, а некоторые драйверы также создают другие псевдонимы в системе. Например, драйвер устройства, реализующий имя "C:\", имеет собственное пространство имен, которое также является файловой системой.

API, использующие функцию CreateFile, обычно работают с префиксом "\\.\", поскольку функция CreateFile используется для открытия как файлов, так и устройств, в зависимости от используемых вами параметров.

Если вы работаете с функциями Windows API, вы должны использовать префикс "\\.\" для доступа только к устройствам, а не к файлам.

Большинство API не поддерживают "\\.\"; только те, которые предназначены для работы с пространством имен устройств, распознают его. Всегда проверяйте справочную тему для каждого API, чтобы быть уверенным.

Пространства имен NT

Существуют также API, позволяющие использовать соглашение о пространстве имен NT, но диспетчер объектов Windows в большинстве случаев делает это ненужным. Для иллюстрации полезно просматривать пространства имен Windows в обозревателе системных объектов с помощью инструмента Windows Sysinternals WinObj. Когда вы запускаете этот инструмент, вы видите пространство имен NT, начинающееся с корня, или "\". Подпапка под названием "Global??" где находится пространство имен Win32. Объекты именованных устройств находятся в пространстве имен NT в подкаталоге «Device». Здесь вы также можете найти Serial0 и Serial1, объекты устройства, представляющие первые два COM-порта, если они есть в вашей системе. Объект устройства, представляющий том, может иметь вид HarddiskVolume1, хотя числовой индекс может отличаться. Имя «DR0» в подкаталоге «Harddisk0» является примером объекта устройства, представляющего диск, и т. д.

Чтобы сделать эти объекты устройств доступными для приложений Windows, драйверы устройств создают символическую ссылку (символическую ссылку) в пространстве имен Win32 "Global??" на соответствующие объекты устройств. Например, COM0 и COM1 в разделе "Глобальные??" подкаталог — это просто символическая ссылка на Serial0 и Serial1, «C:» — это символическая ссылка на HarddiskVolume1, «Physicaldrive0» — это символическая ссылка на DR0 и так далее. Без символической ссылки указанное устройство «Xxx» не будет доступно ни одному приложению Windows, использующему соглашения о пространстве имен Win32, как описано ранее. Однако дескриптор этого устройства может быть открыт с помощью любых API, поддерживающих абсолютный путь пространства имен NT в формате "\Device\Xxx".

С добавлением многопользовательской поддержки через службы терминалов и виртуальные машины возникла необходимость в виртуализации общесистемного корневого устройства в пространстве имен Win32. Это было достигнуто путем добавления символической ссылки с именем «GLOBALROOT» в пространство имен Win32, которое вы можете увидеть в «Global??» подкаталог инструмента браузера WinObj, который обсуждался ранее, и может получить доступ через путь «\\?\GLOBALROOT». Этот префикс гарантирует, что путь, следующий за ним, соответствует истинному корневому пути диспетчера системных объектов, а не пути, зависящему от сеанса.

Читайте также: