Только что начал немного читать о файловой системе Linux. В нескольких местах я находил цитаты вроде этой:
Каталоги Unix представляют собой списки структур ассоциаций, каждая из которых содержит одно имя файла и один номер инода.
Поэтому я ожидал узнать, что каждый каталог будет содержать имена файлов в нем, причем каждый файл будет сопоставлен с inode. Но когда я делаю это vim directory_nameв Ubuntu, я получаю что-то вроде этого:
" ============================================================================
" Netrw Directory Listing (netrw v156)
" /Users/user/workspace/folder
" Sorted by name
" Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$
" Quick Help: <F1>:help -:go up dir D:delete R:rename s:sort-by x:special
" ==============================================================================
../
./
folder1/
folder2/
file1
file2
Я ожидал увидеть номер инода рядом с каждым именем файла. Почему это не так?
решение1
Эта цитата о том, как (логически — фактические структуры в настоящее время часто сильно отличаются) работают файловые системы Unix. И вы можете увидеть номера inode, например, с флагом -ito ls:
$ ls -li
total 8
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw-r--r-- 1 anthony anthony 70 Apr 25 12:07 b
Это число слева — инода. И если я запущу ln b c(создание жесткой ссылки), то:
$ ls -li
total 12
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw-r--r-- 2 anthony anthony 70 Apr 25 12:07 b
532540 -rw-r--r-- 2 anthony anthony 70 Apr 25 12:07 c
Права и размер являются частью inode, а не каталога. Достаточно легко увидеть, что происходит после chmod 0600 c:
$ ls -li
total 12
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw------- 2 anthony anthony 70 Apr 25 12:07 b
532540 -rw------- 2 anthony anthony 70 Apr 25 12:07 c
оба bи cизменены, поскольку они имеют один и тот же индексный дескриптор.
Однако ядро только раскрывает файловую систему пользовательскому пространству через четко определенный API (за исключением необработанных устройств, таких как /dev/sda1). Оно предоставляет пользовательскому пространству доступ к куче системных вызовов для выполнения таких действий, как создание и удаление ссылок, изменение разрешений, чтение и запись файлов, переименование и т. д. Оно не раскрывает необработанные, базовые структуры данных файловой системы пользовательскому пространству. Этому есть ряд веских причин: оно допускает сетевые файловые системы, это означает, что ядро может принудительно применять разрешения и поддерживать корректные структуры данных файловой системы, это означает, что вы можете использовать разные файловые системы (с разными структурами данных) без необходимости изменения пользовательского пространства.
Так что, в принципе, vim dirэто просто показывает вам список каталогов — более или менее как lsэто делает. Это делается через модуль vim под названием Netrw, как говорится в начале (попробуйте :help netrwв vim). На самом деле вы не можете редактировать базовые структуры данных файловой системы.
решение2
Каталог, семантически говоря, является отображением имени файла в inode. Так спроектирована абстракция дерева каталогов, соответствующая интерфейсу между приложениями и файловыми системами. Приложения могут обозначать файлы по имени и перечислять список файлов в каталоге, и каждый файл имеет уникальный идентификатор, который называется «inode».
То, как эта семантика реализуется, зависит от типа файловой системы. Каждая файловая система сама решает, как кодировать каталог. В большинстве файловых систем Unix каталог — это отображение имен файлов в номера инодов, и есть отдельная таблица, отображающая номера инодов в данные инодов. (Данные инодов содержат метаданные файла, такие как разрешения и временные метки, расположение содержимого файла и т. д.) Отображение может быть списком, хэш-таблицей, деревом...
Вы не можете увидеть это отображение с помощью Vim. Vim не показывает область хранения, которая представляет каталог. Linux, как и многие другие современные системы Unix, не позволяет приложениям видеть представление каталога напрямую. Каталоги ведут себя как обычные файлы, когда дело касается их записи каталога и их метаданных, но не когда дело касается их содержимого. Приложения читают из обычного файла с помощью системных вызовов, таких как open, read, write, close; для каталогов есть другие системные вызовы: opendir, readdir, closedir, а изменение каталога выполняется путем создания, перемещения и удаления файлов. Приложение, такое как catиспользует open, read, closeдля чтения содержимого файла; приложение, такое как lsиспользует opendir, readdir, closedirдля чтения содержимого каталога. Vim обычно работает как catдля чтения содержимого файла, но если вы попросите его открыть каталог, он работает как lsи выводит данные в красиво отформатированном виде.
Если вы хотите увидеть, как выглядит каталог изнутри, вы можете использовать такой инструмент, как debugfsдля ext2/ext3/ext4. Убедитесь, что вы ничего не изменяете! Такой инструмент debugfsобходит файловую систему и может полностью ее уничтожить. ext2/ext3/ext4 debugfsбезопасен, поскольку находится в режиме только для чтения, если вы явно не разрешите запись через параметр командной строки.
# debugfs /dev/root
debugfs 1.42.12 (29-Aug-2014)
debugfs: dump / /tmp/root.bin
debugfs: quit
# od -t x1 /tmp/root.bin
Вы увидите имена записей каталогов среди /множества других символов, некоторые из которых непечатаемы. Чтобы разобраться, вам нужно знать подробности формата файловой системы.
решение3
Я подозреваю, что вы читаете очень, очень старое описание того, как работает файловая система Unix. То, что вы описываете, было бы верно в конце 1970-х или около того, но это больше не верно ни для одной современной файловой системы.
На многих современных платформах существует несколько файловых систем, которые широко используются, и каждая из них скрывает свои внутренние компоненты от пользовательского пространства. Вы можете узнать, как они выглядят, и поиграться с ними, но если вы не хотите специализироваться на проектировании файловых систем, возможно, лучше просто довериться автору книги, который даст вам достаточно информации для базового понимания дизайна, не вдаваясь в слишком большие подробности (некоторые из которых устареют к тому времени, когда они вам снова понадобятся).