Что такое файловый описатель
Файловые дескрипторы Linux
Основными операциями, предоставляемыми ядром операционной системы программам (а точнее — процессам) для работы с файлами, являются системные вызовы open read, write и close. В соответствии со своими именами, эти системные вызовы предназначены для открытия и закрытия файла, для чтения из файла и записи в файл. Дополнительный системный вызов ioctl (input output control) используется для управления драйверами устройств и, как следствие, применяется в основном для специальных файлов устройств.
При запросе процесса на открытие файла системным вызовом оpen производится его однократный (относительно медленный) поиск имени файла в дереве каталогов и для запросившего процесса создается так называемый файловый дескриптор (описатель, от англ, descriptor).
Файловый дескриптор «содержит» информацию, описывающую файл, например индексный дескриптор inode файла на файловой системе, номера major и minor устройства, на котором располагается файловая система файла, режим открытия файла, и прочую служебную информацию.
При последующих операциях read и write доступ к самим данным файла происходит с использованием файлового дескриптора (что исключает медленный поиск файла в дереве каталогов).
Файловые дескрипторы пронумерованы и содержатся в таблице открытых процессом файлов, которую можно получить при помощи диагностической программы lsof.
В обратную сторону получить список процессов, открывших тот или иной файл, можно при помощи программ lsof и fuser, что бывает полезно для идентификации программ, «занявших» файловую систему, подлежащую отмонтированию.
Таблица файловых дескрипторов
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
# lsof /dev/log
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd 543 syslog 0u unix 0xefef5680 0t0 1338 /dev/log
# fuser /dev/log
# ps p 543
# lsof /var/log/syslog
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd 543 syslog lw REG 252,0 29039 26214496 /var/log/syslog
В первом примере из листинга выше показано получение списка файловых дескрипторов (столбец FD) процесса командного интерпретатора bash пользователя john, на котором файловый дескриптор номер 1 описывает открытый на чтение и запись и специальный символьный CHR файл устройства /dev/pts/2.
Во втором примере показано получение информации о процессе, открывшем файловый сокет unix с именем /dev/log (файловый дескриптор номер 0 на чтение и запись u) и обычный файл REG с именем /var/log/sysog (файловый дескриптор номер 1 на запись w).
Пронаблюдать за использованием системных вызовов файлового программного интерфейса в момент выполнения программам позволяет системный трассировщик strace.
Трассировка файлового программного интерфейса
$ date
Вт. окт. 15 18:17:42 MSK % 2018
open(«/etc/localtime», 0_RDONLY|0_CLOEXEC) = 3
$ file /etc/localtime
/etc/localtime: timezone data, version 2, 13 gmt time flags, 13 std time flags, no leap
seconds, 77 transition tines, 13 abbreviation char
[email protected]:
Предположив, что программа date показывает правильное московское время, потому что узнаёт заданную временную зону MSK из некоего конфигурационного файла операционной системы, при трассировке ее «работы можно установить его точное имя — /etc/localtime.
Аналогично предположив, что программа eject открывает лоток привода CD/DVD при помощи специального файла устройства, при трассировке можно узнать имя файла /dev/sr0, номер файлового дескриптора при работе с файлом 3 и команду CDROMEJECT соответствующего устройству
драйвера ioctl_List.
Трассировка команды setleds показывает, что она вообще не открывает никаких файлов, но пользуется файловым дескриптором о так называемого стандартного потока ввода (прикрепленного, к текущему терминалу) и командами kdgetled и kdsetled драйвера консоли console_ioctl.
Простыми словами, что такое файловые дескрипторы?
Что могло бы быть более упрощенным описанием файловых дескрипторов по сравнению с описанием в Википедии? Зачем они нужны? Скажем, возьмем в качестве примера процессы оболочки, и как это применимо?
Содержит ли таблица процессов более одного дескриптора файла. Если да, то почему?
11 ответов
Точно так же, когда вы открываете сетевой сокет, он также представляется целым числом и называется дескриптором сокета. Надеюсь, ты понимаешь.
Другие ответы добавили отличные вещи. Я добавлю только свои 2 цента.
Дескрипторы файлов привязаны к идентификатору процесса.
Скажем, возьмем в качестве примера процессы оболочки, и как это применимо?
Посмотрите этот код
4-й столбец FD и следующий за ним столбец TYPE соответствуют файловому дескриптору и типу файлового дескриптора.
Некоторые из значений FD могут быть:
Но настоящий файловый дескриптор находится под:
Символ после числа, например, «1u», представляет режим, в котором открывается файл. r для чтения, w для записи, u для чтения и записи.
TYPE указывает тип файла. Некоторые из значений TYPE:
Также обратите внимание, что таблица дескрипторов файлов, которую отслеживает ядро, не то же самое, что таблица файлов или таблица индексных дескрипторов. Это отдельные, как объяснялось в некоторых других ответах.
Вы можете спросить себя, где физически находятся эти файловые дескрипторы и что хранится, например, в /dev/pts/6
Напомним, что большинство операционных систем Linux определяют семь типов файлов:
Дополнительные сведения о File Descriptor :
FD распределяются в последовательном порядке, что означает наименьшее возможное нераспределенное целочисленное значение.
FD для конкретного процесса можно увидеть в /proc/$pid/fd (в системах на основе Unix).
Дескрипторы файлов
В любой операционной системе есть запущенные процессы (p), например p1, p2, p3 и т. Д. Каждый процесс обычно постоянно использует файлы.
Каждый процесс состоит из дерева процессов (или таблицы процессов, другими словами).
Обычно операционные системы представляют каждый файл в каждом процессе числом (то есть в каждом дереве / таблице процессов).
Любое такое число является дескриптором файла.
Дескрипторы файлов обычно представляют собой целые числа (0, 1, 2, а не 0,5, 1,5, 2,5).
Учитывая, что мы часто описываем процессы как «таблицы процессов», и учитывая, что таблицы имеют строки (записи), мы можем сказать, что ячейка дескриптора файла в каждой записи используется для представления всей записи.
Аналогичным образом, когда вы открываете сетевой сокет, он имеет дескриптор сокета.
В некоторых операционных системах у вас могут закончиться файловые дескрипторы, но такой случай крайне редок, и рядовому пользователю компьютера не стоит беспокоиться об этом.
Дескрипторы файлов могут быть глобальными (процесс A начинается, скажем, с 0 и заканчивается, например, с 1; процесс B начинается, скажем, с 2, и заканчивается, например, с 3) и так далее, но, насколько мне известно, обычно в современных операционных системах файл дескрипторы не являются глобальными и фактически зависят от процесса (процесс A начинается, скажем, с 0 и заканчивается, скажем, с 5, а процесс B начинается с 0 и заканчивается, скажем, с 10).
Дополнение к прежде всего упрощенным ответам.
Если вы работаете с файлами в сценарии bash, лучше использовать файловый дескриптор.
Например: если вы хотите читать и записывать из / в файл «test.txt», используйте дескриптор файла, как показано ниже:
Когда мы открываем существующий файл или создаем новый файл, ядро возвращает файловый дескриптор процессу. Ядро поддерживает таблицу всех открытых файловых дескрипторов, которые используются. Распределение файловых дескрипторов обычно происходит последовательно, и они назначаются файлу в качестве следующего свободного файлового дескриптора из пула свободных файловых дескрипторов. Когда мы закрываем файл, дескриптор файла освобождается и становится доступным для дальнейшего распределения.
Смотрите это изображение для более подробной информации:
Файл дескриптор в Linux с примерами
Однажды, на одном интервью меня спросили, что ты будешь делать, если обнаружишь неработающий сервис из-за того, что на диске закончилось место?
Конечно же я ответил, что посмотрю, чем занято это место и если возможно, то почищу место.
Тогда интервьюер спросил, а что если на разделе нет свободного места, но и файлов, которые бы занимали все место, ты тоже не видишь?
На это я сказал, что всегда можно посмотреть открытые файл дескрипторы, например командой lsof и понять какое приложение заняло все доступное место, а дальше можно действовать по обстоятельствам, в зависимости от того, нужны ли данные.
Интервьюер прервал меня на последнем слове, дополнив свой вопрос: «Предположим, что данные нам не нужны, это просто дебаг лог, но приложение не работает из-за того, что не может записать дебаг»?
«окей», — ответил я, «мы можем выключить дебаг в конфиге приложения и перезапустить его».
Интервьюер возразил: «Нет, приложение мы перезапустить не можем, у нас в памяти все еще хранятся важные данные, а к самому сервису подключены важные клиенты, которых мы не можем заставлять переподключаться заново».
«ну хорошо», сказал я, «если мы не можем перезапускать приложение и данные нам не важны, то мы можем просто очистить этот открытый файл через файл дескриптор, даже если мы его не видим в команде ls на файловой системе».
Интервьюер остался доволен, а я нет.
Тогда я подумал, почему человек, проверяющий мои знания, не копает глубже? А что, если данные все-таки важны? Что если мы не можем перезапускать процесс, и при этом этот процесс пишет на файловую систему в раздел, на котором нет свободного места? Что если мы не можем потерять не только уже записанные данные, но и те данные, что этот процесс пишет или пытается записать?
Тузик
В начале моей карьеры я пытался создать небольшое приложение, в котором нужно было хранить информацию о пользователях. И тогда я думал, а как мне сопоставить пользователя к его данным. Есть, например, у меня Иванов Иван Иваныч, и есть у него какие-то данные, но как их подружить? Я могу указать напрямую, что собака по имени «Тузик» принадлежит этому самому Ивану. Но что, если он сменит имя и вместо Ивана станет, например, Олей? Тогда получится, что наша Оля Ивановна Иванова больше не будет иметь собаки, а наш Тузик все еще будет принадлежать несуществующему Ивану. Решить эту проблему помогла база данных, которая каждому пользователю давала уникальный идентификатор (ID), и мой Тузик привязывался к этому ID, который, по сути, был просто порядковым номером. Таким образом хозяин у тузика был с ID под номером 2, и на какой-то момент времени под этим ID был Иван, а потом под этим же ID стала Оля. Проблема человечества и животноводства была практически решена.
Файл дескриптор
Проблема файла и программы, работающей с этим файлом, примерно такая же как нашей собаки и человека. Предположим я открыл файл под именем ivan.txt и начал в него записывать слово tuzik, но успел записать только первую букву «t» в файл, и этот файл был кем-то переименован, например в olya.txt. Но файл остался тем же самым, и я все еще хочу записать в него своего тузика. Каждый раз при открытии файла системным вызовом open в любом языке программирования я получаю уникальный ID, который указывает мне на файл, этот ID и есть файл дескриптор. И совершенно не важно, что и кто делает с этим файлом дальше, его могут удалить, его могут переименовать, ему могут поменять владельца или забрать права на чтение и запись, я все равно буду иметь к нему доступ, потому что на момент открытия файла у меня были права для его чтения и/или записи и я успел начать с ним работать, а значит должен продолжать это делать.
В Linux библиотека libc открывает для каждого запущенного приложения(процесса) 3 файл дескриптора, с номерами 0,1,2. Больше информации вы можете найти по ссылкам man stdio и man stdout
Список файл дескрипторов можно посмотреть у любого процесса, если вы знаете его PID.
Например, откроем консоль с bash и посмотрим PID нашего процесса
Во второй консоли запустим
Файл дескриптор с номером 255 можете смело игнорировать в рамках данной статьи, он был открыт для своих нужд уже самим bash, а не прилинкованной библиотекой.
Сейчас все 3 файл дескриптора связаны с устройством псевдотерминала /dev/pts, но мы все равно можем ими манипулировать, например запустим во второй консоли
И в первой консоли мы увидим
Redirect и Pipe
Вы можете легко переопределить эти 3 файл дескриптора в любом процессе, в том числе и в bash, например через трубу(pipe), соединяющую два процесса, смотрим
Наш родительский процесс bash с PID 15771 парсит нашу команду и понимает сколько именно команд мы хотим запустить, в нашем случае их две: cat и sleep. Bash знает что ему нужно создать два дочерних процесса, и объединить их одной трубой. Итого bash потребуется 2 дочерних процесса и один pipe.
Перед созданием дочерних процессов bash запускает системный вызов pipe и получает новые файл дескрипторы на временный буфер pipe, но этот буфер никак пока не связывает наши два дочерних процесса.
Для родительского процесса это выглядит так будто pipe уже есть, а дочерних процессов еще нет:
Затем с помощью системного вызова clone bash создает два дочерних процесса, и наши три процесса будут выглядеть так:
Не забываем, что clone клонирует процесс вместе со всеми файл дескрипторами, поэтому в родительском процессе и в дочерних они будут одинаковые. Задача родительского процесса с PID 15771 следить за дочерними процессами, поэтому он просто ждет ответ от дочерних.
Следовательно pipe ему не нужен, и он закрывает файл дескрипторы с номерами 3 и 4.
В первом дочернем процессе bash с PID 9004, системным вызовом dup2, меняет наш STDOUT файл дескриптор с номером 1 на файл дескриптор указывающий на pipe, в нашем случае это номер 3. Таким образом все, что первый дочерний процесс с PID 9004 будет писать в STDOUT, будет автоматически попадать в буфер pipe.
Во втором дочернем процессе с PID 9005 bash меняет с помощью dup2 файл дескриптор STDIN с номером 0. Теперь все, что будет читать наш второй bash с PID 9005, будет читать из pipe.
После этого в дочерних процессах так же закрываются файл дескрипторы с номерами 3 и 4, так как они более не используются.
Файл дескриптор 255 я намеренно игнорирую, он использует для внутренних нужд самого bash и в дочерних процессах будет также закрыт.
Далее в первом дочернем процессе с PID 9004 bash запускает с помощью системного вызова exec исполняемый файл, который мы указали в командной строке, в нашем случае это /usr/bin/cat.
Во втором дочернем процессе с PID 9005 bash запускает второй исполняемый файл, который мы указали, в нашем случае это /usr/bin/sleep.
Системный вызов exec не закрывает файл дескрипторы, если они не были открыты с флагом O_CLOEXEC во время выполнения вызова open. В нашем случае после запуска исполняемых файлов все текущие файл дескрипторы сохранятся.
Проверяем в консоли:
Как видите уникальный номер нашего pipe у нас в обоих процессах совпадает. Таким образом у нас есть связь между двумя разными процессами с одним родителем.
Для тех, кто не знаком с системными вызовами, которые использует bash, крайне рекомендую запустить команды через strace и посмотреть, что происходит внутри, например, так:
Вернемся к нашей проблеме с нехваткой места на диске и попыткой сохранить данные без перезапуска процесса. Напишем небольшую программу, которая будет записывать на диск примерно 1 мегабайт в секунду. При этом если по какой-либо причине мы не смогли записать данные на диск, мы будем просто игнорировать это и пытаться записать данные вновь через секунду. В примере я использую Python, вы можете использовать любой другой язык программирования.
Запустим программу и посмотрим на файл дескрипторы
Как видим у нас есть наши 3 стандартные файл дескрипторы и еще один, который мы открыли. Проверим размер файла:
данные пишутся, пробуем поменять права на файл:
Видим, что данные все еще пишутся, хотя наш пользователь не имеет права писать в файл. Попробуем его удалить:
Куда пишутся данные? И пишутся ли вообще? Проверяем:
Да, наш файл дескриптор все еще существует, и мы можем работать с этим файл дескриптором как с нашим старым файлом, мы можем его читать, очищать и копировать.
Смотрим на размер файла:
Размер файла 19923457. Пробуем очистить файл:
Как видим размер файла только увеличивается и наш транкейт не сработал. Обратимся к документации по системному вызову open. Если при открытии файла мы используем флаг O_APPEND, то при каждой записи операционная система проверяет размер файла и пишет данные в самый конец файла, причем делает это атомарно. Это позволяет нескольким тредам или процессам писать в один и тот же файл. Но в нашем коде мы не используем этот флаг. Мы можем увидеть другой размер файла в lsof после транкейт только если откроем файл для дозаписи, а значит в нашем коде вместо
мы должны поставить
Проверяем с «w» флагом
Программируем уже запущенный процесс
Часто программисты при создании и тестировании программы используют дебагеры (например GDB) или различные уровни логирования в приложении. Linux предоставляет возможность фактически писать и менять уже запущенную программу, например менять значения переменных, устанавливать breakpoint и тд и тп.
Возвращаясь к оригинальному вопросу с нехваткой места на диске для записи файла, попробуем сэмулировать проблему.
Создадим файл для нашего раздела, который мы подмонтируем как отдельный диск:
Создадим файловую систему:
Подмонтируем файловую систему:
Создаем директорию с нашим владельцем:
Откроем файл только на запись в нашей программе:
Ждем несколько секунд
Итак, мы получили проблему, описанную в начале этой статьи. Свободного места 0, занятого 100%.
Мы помним, что по условиям задачи мы пытаемся записать очень важные данные, которые нельзя потерять. И при этом нам нужно починить сервис без перезапуска процесса.
Допустим, у нас все же есть место на диске, но в другом разделе, например в /home.
Попробуем «перепрограммировать на лету» наш код.
Смотрим PID нашего процесса, который съел все место на диске:
Подключаемся к процессу через gdb
Смотрим открытые файл дескрипторы:
Смотрим информацию о файл дескрипторе с номером 3, который нас интересует
Помня о том, какой системный вызов делает Python (смотрите выше, где мы запускали strace и находили вызов open), обрабатывая наш код для открытия файла, мы делаем то же самое самостоятельно от имени нашего процесса, но биты O_WRONLY|O_CREAT|O_TRUNC нам нужно заменить на числовое значение. Для этого открываем исходники ядра, например тут и смотрим какие флаги за что отвечают
#define O_WRONLY 00000001
#define O_CREAT 00000100
#define O_TRUNC 00001000
Объединяем все значения в одно, получаем 00001101
Запускаем наш вызов из gdb
Итак мы получили новый файл дескриптор с номером 4 и новый открытый файл на другом разделе, проверяем:
Мы помним пример с pipe — как bash меняет файл дескрипторы, и уже выучили системный вызов dup2.
Пробуем подменить один файл дескриптор другим
Закрываем файл дескриптор 4, так как нам он не нужен:
Проверяем новый файл:
Как видим, данные пишутся в новый файл, проверяем старый:
Данные не потеряны, приложение работает, логи пишутся в новое место.
Немного усложним задачу
Представим, что данные нам важны, но места на диске у нас нет ни в одном из разделов и подключить диск мы не можем.
Что мы можем сделать, так это перенаправить куда-то наши данные, например в pipe, а данные из pipe в свою очередь перенаправить в сеть через какую-либо программу, например netcat.
Мы можем создать именованный pipe командой mkfifo. Она создаст псевдофайл на файловой системе, даже если на ней нет свободного места.
Перезапускаем приложение, и проверяем:
Места на диске нет, но мы успешно создаем там именованный pipe:
Теперь нам надо как-то завернуть все данные, что попадают в этот pipe на другой сервер через сеть, для этого подойдет все тот же netcat.
На сервере remote-server.example.com запускаем
На нашем проблемном сервере запускаем в отдельном терминале
Теперь все данные, которые попадут в pipe автоматически попадут на stdin в netcat, который их отправит в сеть на порт 7777.
Все что нам осталось сделать это начать писать наши данные в этот именованный pipe.
У нас уже есть запущенное приложение:
Из всех флагов нам нужен только O_WRONLY так как файл уже существует и очищать нам его не нужно
Проверяем удаленный сервер remote-server.example.com
Данные идут, проверяем проблемный сервер
Данные сохранились, проблема решена.
Пользуясь случаем, передаю привет коллегам из компании Degiro.
Слушайте подкасты Радио-Т.
В качестве домашнего задания предлагаю подумать, что будет в файл дескрипторах процесса cat и sleep если запустить такую команду:
Что такое файловые дескрипторы, объясненные в простых терминах?
что было бы более упрощенным описанием файловых дескрипторов по сравнению с Wikipedia? Зачем они нужны? Скажем, возьмем в качестве примера процессы shell и как они применяются для этого?
содержит ли таблица процессов более одного файлового дескриптора. Если да, то почему?
10 ответов
простыми словами, когда вы открываете файл, операционная система создает запись для представления этого файла и хранения информации об этом открытом файле. Поэтому, если в вашей ОС открыто 100 файлов, то в ОС будет 100 записей (где-то в ядре). Эти записи представлены целыми числами, такими как (. 100, 101, 102. ). Этот номер записи является дескриптором файла. Таким образом, это просто целое число, которое однозначно представляет открытый файл в операционной системе. Если процесс открывает 10 файлы тогда ваша таблица процессов будет иметь 10 записей для файловых дескрипторов.
аналогично, когда вы открываете сетевой сокет, он также представлен целым числом и называется дескриптором сокета. Надеюсь, вы понимаете.
услышать это из уст лошади: APUE (Ричард Стивенс).
На ядро все открытые файлы ссылаются файловыми дескрипторами. Файловый дескриптор-неотрицательное число.
когда мы открываем существующий файл или создать новый файл, ядро возвращает файловый дескриптор процесса. ядро поддерживает таблицу всех открытых файловых дескрипторов, которые используются. Выделение файловых дескрипторов обычно является последовательным, и они выделяются в файл в качестве следующего свободного файлового дескриптора из пула свободных файловых дескрипторов. Когда мы закрываем файл, дескриптор файла освобождается и доступен для дальнейшего выделения.
См. это изображение для получения более подробной информации:
когда мы хотим прочитать или записать файл, то найдите файл с дескриптором файла, который был возвращен открыть() или create () вызов функции и используйте его в качестве аргумента либо read () или write ().
По соглашению, системные оболочки UNIX связывают файловый дескриптор 0 с Стандартный Ввод процесса, файловый дескриптор 1 с Стандартный Вывод, и файл desciptor 2 с Стандартная Ошибка.
Файловый дескриптор колеблется от 0 до OPEN_MAX.
Для получения дополнительной информации пройдите 3-ю главу книги APUE.
в дополнение к другим ответам unix рассматривает все как файловую систему. Клавиатуре-это файл, который читается только с точки зрения ядра. Экран-это файл только для записи. Аналогично, папки, устройства ввода-вывода и т. д. также считаются файлами. Всякий раз, когда файл открыт, скажем, когда драйверы устройств[для файлов устройств] запрашивают open () или процесс открывает файл пользователя, ядро выделяет файловый дескриптор, целое число, указывающее доступ к этому файлу, например быть прочитанным только, напишите только etc. [для справки : https://en.wikipedia.org/wiki/Everything_is_a_file ]
больше очков в отношении File Descriptor :
FD распределяются в последовательном порядке, что означает наименьшее возможное нераспределенное целое значение.
FD для определенного процесса можно увидеть в /proc/$pid/fd (в системах на базе Unix).
любая операционная система имеет запущенные процессы (p), скажем p1, p2, p3 и так далее. Каждый процесс обычно делает постоянное использование файлов.
каждый процесс состоит из дерева процессов (или таблицы процессов, в другой формулировке).
обычно операционные системы представляют каждый файл в каждом процессе by a (то есть в каждом дереве/таблице процессов).
любое такое число является дескриптором файла.
файловые дескрипторы обычно являются целыми числами (0, 1, 2, а не 0.5, 1.5, 2.5).
учитывая, что мы часто описываем процессы как «process-tables», и учитывая, что таблицы имеют строки (записи), мы можем сказать, что ячейка файлового дескриптора в каждой записи использует для представления всей записи.
в аналогичной кстати, когда вы открываете сетевой сокет, он имеет дескриптор сокета.
в некоторых операционных системах у вас могут закончиться файловые дескрипторы, но такой случай крайне редок, и средний пользователь компьютера не должен беспокоиться об этом.
файловые дескрипторы могут быть глобальными (процесс A начинается в 0, а заканчивается в 1 ; Процесс B начинается в 2, а заканчивается в 3) и т. д., Но, насколько я знаю, обычно в современных операционных системах файловые дескрипторы не являются глобальными и являются на самом деле процесс специфичен (процесс A начинается в 0 и заканчивается в 5, в то время как процесс B начинается в 0 и заканчивается в 10).
другие ответы добавили отличный материал. Я добавлю только мои 2 цента.
согласно Википедии, мы точно знаем: дескриптор файла является неотрицательным целым числом. Самое главное, что я думаю, отсутствует, было бы сказать:
файловые дескрипторы привязаны к ID процесса.
скажем, взять shell обрабатывает в качестве примера и как он применяется для него?
проверьте этот код
4-й столбец FD и самый Следующий тип столбца соответствуют файловому дескриптору и типу файлового дескриптора.
некоторые из значений для FD могут быть:
но реальный файловый дескриптор в разделе:
символ после числа i.e «1u», представляет режим, в котором файл открывается. r для чтения, w для записи, u для чтения и записи.
TYPE указывает тип файла. Некоторые из значений типов:
но все файловые дескрипторы Chr-символьный специальный файл (или файл символьного устройства)
Обратите также внимание, что таблица дескрипторов файлов, которую отслеживает ядро, не совпадает с таблицей файлов или таблицей индексов. Они разделены, как объяснялось в некоторых других ответах.
вы можете спросить себя, где эти файловые дескрипторы физически и то, что хранится в /dev/pts/6 например
просто вспомнить большинство Linux, как OS определить семь типов файлов:
файловые дескрипторы (FD) :
дескриптор файла для стандартной ошибки 2.
Если нет никакого каталога с именем mydir, то вывод команды будет сохранен в файл errorfile.txt
Используя «2>», мы перенаправляем вывод ошибки в файл с именем » errorfile.txt»
Таким образом, вывод программы не загроможден ошибками.
надеюсь, вы получили ответ.
файловые дескрипторы
файловые дескрипторы-это дескрипторы файла. Они дают ссылки на файл. С их помощью мы можем читать, писать и открывать файлы.