Linux.yaroslavl.ru
| Всё Является Файлом | ||
|---|---|---|
| Пред. | Глава 9. Файловая Система Linux | След. |
Всё Является Файлом
Стартовое Руководство Пользователя описывает концепцию прав доступа к файлам, а также понятия владельца файла, но в действительности для файловых систем UNIX (это относится и к GNU/Linux’ ext2fs) требуется, чтобы мы ввели определение файла.
В данном случае, “всё” действительно означает всё. Жесткий диск, разделы на жестком диске, параллельные порты, подключение к web-сайтам, Ethernet карточка, все они являются файлами. Даже каталоги — это файлы. В GNU/Linux существует много типов файлов в дополнение к стандартным файлам и каталогам. Обратите внимание, здесь под типом файла, мы не подразумеваем содержимое файла: в GNU/Linux и любой другой UNIX системах, файл, будь это текст, или PNG картинка, или двоичный файл, или что-то подобное, является только потоком байтов. Разделение файлов согласно их содержанию оставлено приложениям.
Различные Типы Файлов
Если вы помните, при вводе команды ls -l, символ перед правами доступа идентифицирует тип файла. Мы уже видели два типа файлов: обычный файл (-) и каталог (d). Блуждая по диску, вы также можете встретить и другие типы файлов:
Символьные файлы: это любые специальные системные файлы (типа /dev/null, который мы уже обсуждали), или периферийные устройства (последовательные или параллельные порты), которые разрешают совместное использование своего содержания без буферизации (их значение не сохраняется в памяти). Такие файлы идентифицированы символом c.
Файлы блочного доступа: Эти файлы — являются периферийными устройствами, и, в отличие от символьных файлов, их содержание — буферизируется . В эту категорию входят такие файлы, как например: жесткие диски, разделы на жестком диске, дисководы для гибких дискет, CD-ROM, и так далее. Примерами файлов блочного доступа могут служить файлы /dev/hda, /dev/sda5. В результате выполнения команды ls -l, они идентифицированы символомb.
Символические ссылки: эти файлы очень широко используется в Mandrake Linux , например в процедуре запуска системы (см. главу Глава 11. Файлы Загрузки: init sysv). Название этих файлов отражает цель. Символические ссылки связаны с файлом символическим способом, что означает, что такие файлы могут указывать на существующий файл. Подробнее об этом позже в этой главе. Символические ссылки очень часто (и неправильно, что будет показано позже) называют “мягкими (soft) ссылками”. Такие файлы идентифицируются символом 'l'.
Именованные каналы (pipes): очень похожи на каналы, используемые в shell, фактически разница только в том, что такие каналы имеют название. Именованные каналы очень редки. Маловероятно, что вы встретите хотя-бы один во время исследования файлового дерева. На всякий случай сообщаем что символ, идентифицирующий их — 'p'. Чтобы узнать больше об этом, взгляните сюда : “ Анонимные Каналы и Именованные Каналы”.
Сокеты (socket: розетка, разъем): Этот тип файла для всех сетевых подключений. Только некоторые из них имеют названия. Нужно заметить, что сокеты бывают нескольких типов, но эта тема выходит за рамки данной книги. Такие файлы идентифицированы символом 's'.
Вот примеры каждого типа файлов:
Inode
Inode является, вместе с принципом “Все есть файл”, фундаментальной частью файловой системы UNIX. Слово “inode” это сокращение от Information NODE (Информационный УЗЕЛ).
Inodes хранятся на диске в inode table (таблице информационных узлов). Они существуют для всех типов файлов, которые могут храниться в файловой системе, и это включает каталоги, именованные каналы, файлы символьного режима и так далее. Что приводит к другому известному выражению: “inode есть файл”. При помощи inode UNIX идентифицирует файл уникальным способом.
Иначе говоря UNIX не идентифицирует файл по его имени . Вместо этого используется номер [18] из таблицы inode. Причина для этого заключается в том, что файл может иметь несколько названий, или вообще не иметь никакого названия. Имя файла в UNIX, является только указателем на inode. Такой указатель называется link (линк или ссылка). Давайте рассмотрим ссылки более подробно.
[18] Важно: обратите внимание, что номер inode уникален в пределах файловой системы , что означает, что inode с тем же самым номером может существовать на другой файловой системе. Это приводит к различию между дисковым inode и inode в оперативной памяти. Два дисковых inode могут иметь один и тот же номер, если они находятся на двух различных файловых системах. В оперативной памяти inode имеет уникальный номер на всю систему.
Источник
Как понять, что все в Linux- это файлы?
Недавно я узнал, что «в Linux файлом является абсолютно все». Понятно, когда речь идет о каком-то статическом файле, картинке или текстовом файле, тут все ясно.
Но пишут, что процесс или сетевое соединение это тоже файл. Я это представляю как некие переменные/временные данные, которые записывает одна программа/процесс (когда начинает свою работу), и считывает (при надобности) другая. Т.е. некие файлы, в которые постоянно (может, ежесекундно) что-то записывается/перезаписывается.
Но хотелось бы увидеть воочию такой файл «сетевого соединения» или файл «процесса». Открыть его, посмотреть что внутри.
1. Где найти такие файлы в Ubuntu?
2. Есть ли просмотрщик (консольный), который «рефрешит» этот файл ежесекундно, чтобы убедиться что в таком файле постоянно что-то меняется?
3. А в Windows не все- файл? Те же процессы и сетевые соединения там в виде чего представлены?
Файл это абстрактный интерфейс, а не буквально файл, который данные на диске, под твоей типичненькой NTFS.
А как можно «потрогать» этот абстрактный интерфейс? Хочу заглянуть внутрь файла «сетевого соединения» или файла «процесса».
Там много файлов и каталогов. Дай хоть один пример файла сетевого соединения и процесса, и чем их открыть для просмотра (без вреда системе).
Это рекламный слоган. Так сделали в план 9, а в юникс от этого ушли довольно далеко. Хотя какие-то обрезки в файлах можно найти.
В windows всё объект. Там проработанная объектная модель. Местами такую строят и в линуксе, например в KDE/Gnome.
С чего начать?
Рекламный слоган? Я это читал в книжке по Linux пол года назад, а недавно то же самое прочел в статье про Linux. Ну пусть по-твоему, покажите мне где находится сетевое соединение и процесс, и как/чем его открыть и посмотреть что внутри.
потрогай stdin, stdout — они могут быть обычным файлом, пайпом, сетевым сокетом
трогать сетевые сокеты удобно читая книжку Йон Снейдер «Эффективное программирование TCP/IP», если ее осилишь — далеко пойдешь
А она целиком актуальна (2010й год все-таки)? Спасибо, почитаю.
- Есть ли просмотрщик (консольный), который «рефрешит» этот файл ежесекундно, чтобы убедиться что в таком файле постоянно что-то меняется?
Файл, но только не просто обычный файл.
Есть ещё сокеты.
Спасибо, буду экспериментировать. Кроме Progress, нашел еще PV.
Ну и в принципе можешь и дальше сам изучать вывод поисковика по запросу /dev сокет
Но в принципе во всём многообразии тебе реально понадобится только утилиты dd,fdisk,gdisk и mount для работы с файлами блочных устройств(то есть манипуляция образами дисковых разделов) и снятыми с них образами разделов и дисков..
А как можно «потрогать» этот абстрактный интерфейс? Хочу заглянуть внутрь файла «сетевого соединения» или файла «процесса».
Сетевого соединени… Ну например: cat /proc/net/tcp . Но это не будет познавательно для тебя.
Если хочется с необычными файлами поиграться, есть попроще примеры. Скажем, /dev/tty2 (tty3, tty4 и т.д.) — файл виртуальной консоли. Например, сделай echo «Hello World» > /dev/tty2 из-под рута, а потом переключись на вторую консоль (Ctrl+Alt+F2). Скажем /dev/sda (скорее всего так) — файл твоего жёсткого диска. С него ты можешь считать ВЕСЬ жёсткий диск, как единый файл. А забив его нулями, ты забьёшь нулями, соответственно, жёсткий диск (не делай этого — потеряешь данные). Ну ещё есть, например генератор случайных чисел — /dev/urandom. Можешь сделать например head -1 /dev/urandom — получишь строку случайно каши (каждый раз разную, хотя сам ты файл не менял). Хватит пока таких примеров? Больше — смотри все файлы в /dev и в /proc.
Да, более чем достаточно, спасибо. Самое интересное попробую в виртуалке.
Можешь сделать например head -1 /dev/urandom — получишь строку случайно каши
К стати есть команды для генерации пароля:
Смешанные: unset pw; declare pw;while [ $ <#pw>-lt 4 ]; do pw=»$pw$(dd if=/dev/urandom bs=1 count=1 2>/dev/null | grep ‘[a-fA-F0-9]’)»; done; echo $pw Только прописные: unset pw; declare -l pw;while [ $ <#pw>-lt 4 ]; do pw=»$pw$(dd if=/dev/urandom bs=1 count=1 2>/dev/null | grep ‘[a-fA-F0-9]’)»; done; echo $pw Только заглавные: unset pw; declare -u pw;while [ $ <#pw>-lt 4 ]; do pw=»$pw$(dd if=/dev/urandom bs=1 count=1 2>/dev/null | grep ‘[a-fA-F0-9]’)»; done; echo $pw
К стати есть команды для генерации пароля
У меня тоже есть! Кастомный.
Как на работе требуют, 13 знаков минимум, с заглавными, прописными, цифрами и символами. Оставляю только те символы, которые мне не сложно набирать на телефоне.
в Linux файлом является абсолютно все
Это не так (в частности, сетевым интерфейсам никакие файлы не соответствуют).
Вот ещё одна тема, полезная тебе как новичку Делюсь опытом ускорения чтения файловой систем
Даже если файл как бы есть, уложиться в простые операции read/write и тестовые потоки не получается. Появляются всякие ioctl и т.п. и абстракция хромает
Угу. Этакий виртуальный файл в виртуальном каталоге. По сути читаешь память в человекопонятном виде. Устаревшее, как говно мамонта. Для управления не используется уже очень давно. Да и для чтения не актуален. И /dev тоже всего лишь особые ссылки на драйвера. Читать их человеку совершенно бессмысленно. Но как написано! Устройство представляет собой файл в /dev. В настоящее время это тоже виртуальный файл, который хранится в памяти. Раньше были реальные файлы в /dev и хранились на диске, затем появился DevFS, а сейчас udev. Файл он потому, что ядро его воспринимает как имя файла, но файла как такового может и не существовать. Это вопрос пространства имен (https://en.wikipedia.org/wiki/Linux_namespaces). В данном случае, filesystem namespace.
Да и вообще, школьник, забей на линукс. Линукс это большая жопа без ручки, он и ручку поглатил. В нем нет никакого UNIX’а, он GNU’тый до безобразия. Используя бесплатный линукс ты всего лишь являешься тестером работоспособности кода для коммерческих дистрибутивов. Хорошего бесплатно тебе никто и никогда не даст.
А если ты фанатик it, то поверь мне на слово, it только в рашке и сшашке что-то особое. На самом деле херня особо редкая. Я хз почему все рвутся в этот it, но она того не стоит и не стоит. Умного в it нет почти ничего. Если только ради денег, то кроликов разводить на много выгоднее.
Соберись и прочти книгу
Устарело, как и сам Алексей.
Собственно, Алексей пример того, до чего доживают it’шники. Вроде и знает много, а не нужен уже. В 30 лет это уже предпенсионый возраст. В 40 лет если ты гений или удачно пристроил свою задницу и особо ничего не делаешь. В 50 лет ты у дел, если начальник или сисадмин, но уже больной и тупой, все на самотек.
А как можно «потрогать» этот абстрактный интерфейс?
уверовать в это — через это понимание что всё в Linux файл станет пониманием аксиомы.
все(более чем в Linux встречающемся в природе в диких условиях) файл в Plan9 и его (более менее чистых(т.е где с точки той оси plan9( ака pLANix ака plaNIX ака uNIX т.е reseach unix ver 10) )в стволе основном предков )потомках — и успешно(вполне для тех задач) используется у BigCorp ( ака «делай зла» и прочее сектанство 🙁 ) — golang как баребон
и да анекдот — «а то так и останешься подавателям ключа на 12» — применим ко многим ещё окончательно не проффесионализированным областям полезной деятельности.
я узнал, что «в Linux файлом является абсолютно все»
Тебя обманули, это про Plan9.
Ну пусть по-твоему, покажите мне легион устал.
байка «дайте ему лединец»
в практике трейдофф здесь_и_сейчас делает не самые красивые(с точки зрения архитектуры) решения самыми красивыми с точки равновесия[по Нэшу(?)] по экономике внедрения.
в долгую(иногда до нескольких столетий 🙁 время перехода растягивается) красивые по архитектуре более экономичны ибо менее требовательны к девелоперам(в части сопряжения более умопостигаемых интерфейсов)
потрогай stdin, stdout — они могут быть … сетевым сокетом
очень любопытно, че это такое я сейчас прочитал. покажешь, как такое делается без неткатов и башизмов?
Недавно я узнал, что «в Linux файлом является абсолютно все».
Врут. В линуксе этого никогда не было. И в юниксе перестало быть с появлением сокетов.
Где в самом деле «файл есть всё» – так это в plan9. В том числе и мышка и монитор и сетевое соединение и по-моему даже cpu.
Глава 8. Файл как он есть
Еще раз повторюсь, устарело невероятно и к тому же речь исключительно про файловую систему как таковую.
Что такое объект? Это данные и метод их обработки. Данные бывают разные. Описание каталога тоже данные. Потрогать их cat’ом не получится. Уточнение, что за данные, содержится в атрибутах файла (смотреть stat) и в т.н. магии, а точнее, идентификационной сигнатуре (смотреть file). Принадлежность текстовых файлов определяется дополнительно. Как же обработывают эти данные? В Windows метод обработки вызывается по суффиксу файла, например, *.exe, *.pdf. В DE Linux метод обработки данных в начале определяется по суффиксу файла (привязка файлов, ассоциация), затем по магии, если и магия ничего не дала, считается текстовым файлом. Для примера, создадим пустой файл touch file и попробуем его открыть в диспетчере файлов. Будет предложено выбрать приложение для обработки данных. Но стоит добавить к нему суффикс .pdf и DE попытается открыть его как pdf. Исходя из этого, для DE Linux файлы тоже являются объектами.
А что не так с мышкой? Оно везде — файл, даже в ms-dos-е, так как просто тупо генерирует последовательность байткодов от движения и нажатий кнопочек.
в него писать можно и это приводит к очень простым способам автоматизации gui
в него писать можно и это приводит к очень простым способам автоматизации gui
Вы путаете два понятия. Писать в мышку надо, чтобы её инициализировать, поменять скорость и чувствительность. А для прикладного ПО мышка виртуальная, некий программный pointer, включающий в себя события от мыши, стилуса, тачпада и их эмуляции, по своему протоколу, но тоже по сути двунаправленный stream со своим байткодом.
Книга 2005го, информация по состоянию на год так 2000-ый. Устарело на 20 лет, а 20 лет — это, например, дорога от огромных ламповых шкафов без ос, которым задачи скармливались перфолентами, до графических интерфейсов и домашних компов.
Устарело на 20 лет, а 20 лет — это, например, дорога от огромных ламповых шкафов без ос, которым задачи скармливались перфолентами, до графических интерфейсов и домашних компов.
Все аналогии врут. Первые автомобили 130 лет назад были электрические, мало чем отличиющиеся от сегодняшних, ну аккумы были свинцовые и вместо IGBT в контроллерах были реостаты. А в 2000 году Интернет был самым свободным, не чета сегодняшнему, никакой цензуры и сплошной рост доткомов в надежде, что когда-то окупится и потому почти коммунизм с бесплатной информацией. Какие лампы?
И что здесь устарело?
ТС знает, интересно, понятие inode?
Конкретно тут разве что небольшие анахронизмы, вроде «обнаружатся такие файлы, как cdrom, mouse, modem, audio», но в этой главе куча ссылок на 10 главу, в которой, по нынешним временам, написана уже дичь.
Лучше прочесть эту «дичь», делая поправки на современность, чем тыкаться, как мокрые котята. Черпая разрозненные знания из хаутушек.
Можно скопировать CPU и получить удвоение мощности.
в Linux файлом является абсолютно все
Это не так. Так было в ранних unix, но и там от этой абстракции постепенно отошли, а linux появился уже после того, как всё перестало быть файлом.
Но в двух словах суть такова, что все ресурсы системы доступны через файловый интерфейс. В частности устройства представляются в виде файлов в каталоге /dev, различные системные внутренности в виде файлов в /proc и /sys и т.д. Собственно даже каталоги это тоже особый вид файла. Это должно позволять по изначальной задумке работать с устройствами и внутренностями системи с помощью обычных файловых команд, обеспечивая универсальность, а также уменьшить объём системного API. Классический пример (который сейчас уже не работает) cat file.wav > /dev/dsp
Сейчас в linux остался компромиссный вариант. Что сущности по прежнему представляются как файлы, но для того, чтобы управлять связанными с файлами сущностями часто нужно использовать специальные операции через ioctl/fcntl/mmap и т.п. «неклассический» файловый доступ, что не позволяет теперь просто делать cat и т.п.
Кроме того некоторые вещи вообще не имеют файлового представления, в частности сетевые соединения. С ними можно работать только через системный API.
Там такой подход в принципе не используется и полагаются полностью на системный API.
не пойму, ты прикалываешься или чо?
inetd/xinetd может запустить любой скрипт в качестве внешнего сервера. скрипту он отдаст готовый сокет, подцепленный к stdin, stdout, stderr.
может не скрипт запустить, а ftpd или апач например, если тебе неохота их держать постоянно запущенными.
Первые автомобили 130 лет назад были электрические, мало чем отличиющиеся от сегодняшних
В начале была работа «О применении электромагнетизма для приведения в движение машины». За ней лодка поплала на электродвигателе. Потом самоходка по железной дороге. И современная лодка, и самоходка по железке ну совсем не отличаются от первых.
Классический пример (который сейчас уже не работает)
Почему не работает? Я сам не пробовал, но, по описанию, osspd позволяет такое делать.
К слову, этот классический пример — классический обман. В том смысле, что воспроизводится не wav-файл, /dev/dsp принимает сырой поток, просто исторически сложилось, что в WAV кладут LPCM 2ch/44.1kHz/16bit, что и ожидает звуковушка по умолчанию, при этом и заголовок содержит количество байт, кратное 4, что даёт всего лишь несколько незаметных уху мусорных семплов. Если же положить в файл file.wav mono/22.05kHz/8bit, то результат cat’а будет обескураживающим.
Можно же в конвейер вставить какой-нибудь декодер, выдающий сырой поток
Можно, конечно. Мой поинт несколько в другом — этот сырой поток всё равно должен подходить под ожидания /dev/dsp. А эти ожидания настраиваются через ioctl. То есть обычными файловыми утилитами в общем случае воспроизвести звук не получится, тебе всё равно потребуется поговорить с /dev/dsp не как с простым файлом, а как со звуковым устройством.
в системах где систематически проводится интерфейс «всё есть файл» через файл в который поступают состояние с устройства и чтением из которого можно сии состояния учитывать в пользовательской программе как например управляющие события можно(при должном перенаправлении файлов — через теже пайпы и т.п) эмулировать события — т.е. как
в той классической (ака бородатой шутке) что всё есть обьект эквивалентно всё есть файл с «драйверами» событий открыть создать прочитать и записать — т.е есть возможно взаимно однозначное соответствие между «файловым» vs «обьектным» взглядом
т.е ровно то классическое отвязывание от специфики терминального устройства возогнаное до универсального интерфейса открыть/создать/прочитать/записать уровня файла и ещё пару тройку методов жонглирования локальными и глобальными пространствами имён
Источник
