Я читаю этот учебник Unix и наткнулся на эту цитату ...
Здесь следует отметить, что каталог - это просто особый тип файла.
... но никаких объяснений или подробностей не предоставляется. Как каталог на самом деле просто файл?
Ответы:
Многие сущности в операционных системах * nix (и других) считаются файлами или имеют определяющий файловый аспект, даже если они не обязательно являются последовательностью байтов, хранящихся в файловой системе. Как именно реализованы каталоги, зависит от типа файловой системы, но обычно то, что они содержат, рассматривается как список, представляет собой последовательность хранимых байтов, поэтому в этом смысле они не такие уж особенные.
Один из способов определить, что такое «файл» в контексте * nix, - это то, что с ним связан дескриптор файла . Согласно статье в Википедии, дескриптор файла
является абстрактным индикатором, используемым для доступа к файлу или другому ресурсу ввода / вывода , такому как канал или сетевое соединение ...
Другими словами, они относятся к различным видам ресурсов, из которых / может быть прочитана / записана последовательность байтов, хотя источник / назначение этой последовательности не указан. Иными словами, «где» ресурса может быть что угодно. То, что определяет это, - то, что это - канал информации. Это часть того, почему иногда говорят, что в Unix «все является файлом». Вы не должны понимать это буквально, но это стоит серьезного рассмотрения. В случае каталога эта информация относится к тому, что находится в каталоге, и на более низком уровне реализации, как найти его в файловой системе.
В этом смысле каталоги являются чем-то особенным, потому что в нативном C-коде они якобы не связаны с файловым дескриптором; POSIX API использует специальный тип потока ручки, DIR*. Однако этот тип на самом деле имеет базовый дескриптор, который можно получить . Дескрипторы управляются ядром, и доступ к ним всегда включает системные вызовы, поэтому еще один аспект дескриптора состоит в том, что он является каналом, контролируемым ядром ОС. Они имеют уникальные (для процесса) числа, начинающиеся с 0, который обычно является дескриптором для стандартного входного потока.
openatи fstatatт. Д.), Которые используют файловые дескрипторы, ссылающиеся на каталоги.
fsync()только для чтения (!) Каталог fd, и он имеет четко определенный эффект (в частности, он синхронизирует создание / переименование / удаление файла в заданном каталоге на диск, теоретически необходимый шаг в операции «запись»). к временному файлу и переименуйте его поверх оригинальной «идиомы».
В Unix-способе делать вещи: все это файл.
Каталог - это один (из многих) тип специального файла. Он не содержит данных. Вместо этого он содержит указатели на все файлы, содержащиеся в каталоге.
Другие типы специальных файлов:
Но поскольку они считаются «файлами», вы можете lsих переименовывать, перемещать и, в зависимости от типа специального файла, отправлять данные в / из них.
Мой ответ - просто воспоминание, но в 199x винтажных Unix, из которых было много каталогов, были файлы, просто помеченные как «каталог» где-то в иноде на диске.
Вы можете открыть каталог с чем-то вроде open(".", O_RDONLY)и вернуть дескриптор пригодного для использования файла. Вы можете проанализировать содержимое, если вы пролистали /usr/includeи нашли правильное определение структуры C. Я знаю, что сделал это для систем SunOS 4.1.x, файловой системы SGI EFS и любых рабочих станций DEC Mips-CPU для файловой системы, вероятно, BSD4.2 FFS.
Это был плохой опыт. Стандартизация на уровне виртуальной файловой системы - хорошая вещь для переносимости, даже если каталоги больше не являются строгими файлами. Слои VFS позволяют нам экспериментировать с файловыми системами, где каталоги не являются файлами, такими как ReiserFS или NFS.
cp --link dir1/* dir2, хотя я не уверен в его удобстве использования.
Особенность каталога заключается в том, что в его режиме есть буква «d», указывающая файловой системе, что она должна интерпретировать свое содержимое как список других файлов, содержащихся в каталоге, а не обычный файл, представляющий собой последовательность байтов, прочитано приложением. Вот и все.
Каталоги - это файлы, потому что в системах Linux используется универсальная модель ввода / вывода . В модели все в системе является файлом, и к нему можно получить доступ с помощью одних и тех же системных вызовов и различных команд.
Они имеют специальный тип, потому что их i-узлы имеют метку для типа файла, и они имеют специальную структуру, состоящую из таблицы имен файлов и ссылок на другие i-узлы. Эти пары имя-ссылка-ссылка, также известные как «жесткие ссылки» в i-узле каталога, перечисляют файлы «внутри» каталога.
Каталоги только для организации файлов. Когда файл «перемещается» из одного каталога в другой, сам файл не перемещается на диск. Просто запись в одном каталоге i-узлов удаляется и записывается в другой каталог i-узла.
Принятый ответ не совсем правильный. в системах POSIX «Inodes» указывают на файлы и каталоги. Файловые дескрипторы уникальны только для процесса, а не для всей системы. Иноды, тем не менее, уникальны, хотя более одного индекса могут указывать на один файл. Прокомментировал бы принятый ответ, но не смог из-за ограничения повторений.
ls -l >test.txt;ln -vf test.txt test2.txt;ls -li test.txt test2.txt. Итак, вы увидите, что жесткие ссылки имеют одинаковый номер инода.
fork()s, его дочерний процесс будет иметь (за исключением некоторых особых обстоятельств, а именно O_CLOEXECфлага) точно такие же сущности файлового дескриптора, как и у исходного процесса. Другой пример: дочерние процессы apache работают listen()с одним и тем же дескриптором файла сокета. Но этот ответ не о файловых дескрипторах, которые являются внутренней структурой данных ядра и существуют только в памяти ядра. Этот ( ложный ) ответ касается записей каталога и инодов, это сущности на диске (то есть физические байты на жестком диске).
fork()произойдет, а потом дочерний процесс seek()s или close()s, это не повлияет на файловый дескриптор родителя. Итак, я думаю сейчас, что файловые дескрипторы являются лишь частично частными структурами процесса. Но этот вопрос не о них, а о директивах / инодах, и я комментирую вам совершенно ложный ответ на этот вопрос.