1 )В большинстве файловых систем Unix файл, fifo, каталог и т. д. описываются индексным узлом. Инод имеет ряд полей, но наиболее интересным в данном случае является поле режима i _. Рядом с разрешениями он содержит тип «файла», на который указывает индексный дескриптор :

Constant        Value   Description
-- file format --
EXT2_S_IFSOCK   0xC000  socket
EXT2_S_IFLNK    0xA000  symbolic link
EXT2_S_IFREG    0x8000  regular file
EXT2_S_IFBLK    0x6000  block device
EXT2_S_IFDIR    0x4000  directory
EXT2_S_IFCHR    0x2000  character device
EXT2_S_IFIFO    0x1000  fifo

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

Что такое файл?

Файл в Linux — это просто вещь, с которой вы можете взаимодействовать. Существует ровно 7 типов файлов:

• розетка,
• символическая ссылка,
• обычный файл,
• блочное устройство,
каталог
• ,
• символьное устройство,
• FIFO (Труба АКА ).

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

• Файл, представленный на диске (в файловой системе)
• Файл, представленный в Linux ("в памяти")

В Linux (в памяти)

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

• Идентификатор устройства -ссылается на файловую систему или драйвер, отвечающий за файл
• номер инода -уникальный, заданный файловой системой или драйвером. Два инода могут иметь одинаковый номер инода, если у них разные идентификаторы устройства
.
• тип -говорит Linux, что это за файл на самом деле. См. выше.

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

На диске

Различные файловые системы очень разные. Файловые системы, такие как ext4, были написаны для unix и linux и отражают концепцию inodes. Таким образом, иноды в памяти в значительной степени просто считываются из инодов на диске.

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

Номера инодов на диске обычно используются драйвером как номера инодов в Linux. Таким образом, иноды на диске часто ошибочно принимают за то же самое, что иноды в памяти.

Как ссылаться на файлы (иноды )?

Имена файлов

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

Файлы в Linux могут иметь более одного имени. Это возможно только в том случае, если файловая система также поддерживает это. Как в Linux, так и на диске множественные имена файлов (жесткие ссылки )достигаются за счет того, что несколько имен указывают на один и тот же индексный дескриптор.

Удаление файла — это просто удаление его имени. Фактическое занимаемое пространство может быть восстановлено только тогда, когда все имена файлов будут удалены, а все «файловые дескрипторы» закрыты.

Таким образом, для обычных файлов (на диске )есть три вещи :имя файла --> индексный дескриптор --> данные

Дескрипторы файлов

Когда программа открывает файл, она меняет имя файла на дескриптор файла (число ). Это другой вид ссылки на индексный узел, у которого нет имени или пути. Все операции над файлом, такие как «чтение» и «запись», используют дескриптор файла, а НЕ имя файла.

Файловые дескрипторы не обязательно получать через open (). Если у вас есть дескриптор файла, он может быть унаследован (, скопирован )дочерними процессами и даже скопирован в совершенно другой процесс (через сокет домена unix ).

Я думаю, что это вызвало некоторую путаницу, потому что слова «описание файла» использовались в комментарии, на который ссылается ОП. Я считаю, что эти комментарии пытались сказать, что файловые дескрипторы — это больше, чем просто число. Но они сказали это запутанным образом.

Файлы без имени файла или файловой системы

У этой модели есть несколько особенностей. Во-первых, если вы открываете файл, а затем удаляете его (, не закрывая файл ), дескриптор открытого файла предотвращает повторное использование файла на диске. Это приводит к файлу без имени файла.

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

Типичным примером безымянных каналов является STDIN, STDOUT для программы командной строки. Когда вы соединяете две программы вместе (foo | bar), канал между ними будет безымянным каналом.

Заключительные замечания

Обычно мы объединяем все эти понятия в одно слово «файл». Обычно вы можете «записывать в файл», не заботясь о том, что это включает в себя отдельное имя файла, индексный дескриптор, который будет преобразован в имя файла на диске, и индексный дескриптор на диске и, в конечном итоге, запись содержимого на диск. Фраза «записать в файл» означает все это.

Разделять эти понятия нужно только в особых случаях.

TL;DR

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

Файл как абстракция

Давайте обратимся к определениям POSIX 2017, раздел 3.164 , чтобы узнать, как определяется файл:

An object that can be written to, or read from, or both. A file has certain attributes, including access permissions and type. File types include regular file, character special file, block special file, FIFO special file, symbolic link, socket, and directory. Other types of files may be supported by the implementation.

Таким образом, файл — это все, из чего мы можем читать, записывать или и то, и другое.который также имеет метаданные. Всем -домой, дело закрыто!

Ну, не так быстро. Такое определение открывает много места для связанных концепций, и, очевидно, существуют различия между обычными файлами и каналами say. «Все есть файл» само по себе является концепцией и шаблоном проектирования , а не буквальным утверждением. На основе этого шаблона такими типами файлов, как каталоги, каналы, файлы устройств, файлы памяти -, сокеты -, всем этим можно манипулировать с помощью набора системных вызовов, таких как open(), openat(), write(), а в случае розеток recv()и send()последовательно; возьмем, например, USB в качестве аналогии -у вас так много разных устройств, но все они подключаются к одному и тому же порту USB (неважно, что на самом деле существует несколько типов портов USB от A до C, но вы поняли ).

Конечно, для того, чтобы это работало, должен существовать определенный интерфейс или согласованная ссылка на фактические данные, и это файловый дескриптор:

A per-process unique, non-negative integer used to identify an open file for the purpose of file access. The value of a newly-created file descriptor is from zero to {OPEN_MAX}-1.

Таким образом, мы можем write()вывести STDOUT через файловый дескриптор 1 так же, как мы записываем в обычный файл /home/user/foobar.txt. Когда вы open()открываете файл, вы получаете дескриптор файла и можете использовать ту же функцию write()для записи в этот файл. В этом весь смысл того, что оригинальные создатели Unix пытались решить -минималистичное и последовательное поведение. Когда вы сделаете command > /home/user/foobar.txt, оболочка сделает копию файлового дескриптора, который ссылается на foobar.txt, и передаст его как commandфайловый дескриптор 1 (echo STDOUT ), или, если быть более точным, он сделает dup2(3,1), а затем execve()команду. Но независимо от этого commandпо-прежнему будет использовать тот же системный вызов записи в файловый дескриптор 1, как будто ничего не произошло.

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

A file that is a randomly accessible sequence of bytes, with no further structure imposed by the system.

Напротив,у нас есть Розетки:

A file of a particular type that is used as a communications endpoint for process-to-process communication as described in the System Interfaces volume of POSIX.1-2017.

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

Все файлы имеют индексные дескрипторы

В определении файла вы должны были заметить, что у файла есть «определенные атрибуты», которые хранятся в индексных дескрипторах. На самом деле в Linux мы можем ссылаться на индексный дескриптор (7 )руководство первая строка:

Each file has an inode containing metadata about the file. An application can retrieve this metadata using stat(2) (or related calls)

Бум. Ясно и прямо. Мы в основном знакомы с инодами как мостом между блоками данных на диске и именами файлов, хранящимися в каталогах (, потому что это то, что каталоги представляют собой -списки имен файлов и соответствующих инодов ). Даже в виртуальных файловых системах , таких как pipefs и sockfs в ядре, мы можем найти иноды. Возьмем, к примеру, этот фрагмент кода:

static char *pipefs_dname(struct dentry *dent, char *buffer, int buflen)
{
    return dynamic_dname(dentry, buffer, buflen, "pipe:[%lu]",
            dentry->d_inode->i_ino);
}

Открыть описание файла

Теперь, когда вы совсем запутались, Linux/Unix представляет нечто, известное как описание открытого файла, и для простоты объяснения -это еще одна абстракция. По словам Стефана Шазела,

It's more about the the record of how the file was opened more than the file itself.

И это соответствует определению POSIX:

A record of how a process or group of processes is accessing a file. Each file descriptor refers to exactly one open file description, but an open file description can be referred to by more than one file descriptor. The file offset, file status, and file access modes are attributes of an open file description.

Теперь, если мы также посмотрим на книгу Understanding the Linux Kernel , автор утверждает

Linux implements BSD sockets as files that belong to the sockfs special filesystem...More precisely, for every new BSD socket, the kernel creates a new inode in the sockfs special filesystem.

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

_{продолжение следует...может быть}