Как linux сохраняет папку сопоставления -> имя_файла -> inode?

Просто начал немного читать о файловой системе Linux. В нескольких местах я нашел цитаты вроде этого:

Каталоги Unix представляют собой списки структур ассоциаций, каждая из которых содержит одно имя файла и один номер inode.

Поэтому я ожидал узнать, что каждый каталог будет содержать имена файлов под ним, причем каждый файл сопоставляется с 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 

Я ожидал увидеть индексный индекс рядом с каждым именем файла, почему это не так?

  • Быстро найти, какой файл (ы) принадлежит определенному номеру inode
  • Изменяется ли индекс при переименовании или перемещении файла?
  • Почему переименование файла с помощью команды mv изменяет дату и время «изменения» inode?
  • Как изменить размер inode в файле EXT2
  • как выглядит запись «удаленный файл» в журнале
  • Списки каталогов ext4 в виде файла
  • Что такое inode для сокета?
  • Unreferenced inodes для экземпляра EC2 linux
  • 3 Solutions collect form web for “Как linux сохраняет папку сопоставления -> имя_файла -> inode?”

    Каталог является, по-семантически, сопоставлением от имени файла к inode. Так проектируется абстракция дерева каталогов, соответствующая интерфейсу между приложениями и файловыми системами. Приложения могут назначать файлы по имени и перечислять список файлов в каталоге, и каждый файл имеет уникальный указатель, который называется «inode».

    Как реализуется эта семантика, зависит от типа файловой системы. Каждая файловая система зависит от того, как кодируется каталог. В большинстве файловых систем Unix каталог представляет собой сопоставление от имен файлов к номерам inode, и есть отдельная таблица, отображающая номера inode для данных inode. (Данные inode содержат метаданные файлов, такие как разрешения и метки времени, расположение содержимого файла и т. Д.). Отображением может быть список, хеш-таблица, дерево …

    Вы не видите это сопоставление с 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 /dev/root debugfs 1.42.12 (29-Aug-2014) debugfs: dump / /tmp/root.bin debugfs: quit # od -t x1 /tmp/root.bin 

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

    Это цитата о том, как (логически – фактические структуры часто очень разные в наши дни) работают файловые системы Unix. И вы можете видеть номера индексных дескрипторов, например, с флагом -i в 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 bc (создав жесткую ссылку), тогда:

     $ 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 in vim). Вы не можете редактировать основные структуры данных файловой системы.

    Я подозреваю, что вы можете прочитать действительно, действительно старое изложение того, как работает файловая система Unix. То, что вы описали, было бы правдой в конце 1970-х или около того, но это уже не так для любой современной файловой системы.

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

    Interesting Posts

    Запретить расширение переменных в контурах

    Почему «ls | wc -l "показать правильное количество файлов в текущем каталоге?

    java-плагин не работает в Chrome-браузере (все возможные попытки исчерпаны)

    Удалить все скобки в имени файла

    Размер образа ddrescue на диске

    Почему не удается root на одной машине изменить nfs смонтированный контент с другого компьютера?

    Запуск программ с правами root с моим собственным паролем в Scientific Linux / Red Hat / Fedora / CentOS

    Использование поиска для поиска и отправки отчетов, содержащих один, но не два ключевых слова внутри

    Bash: `-su: $ *: несвязанная переменная` с` set -u`

    Переустановка файла tar или tar.gz в файлы меньшего размера tar / tar.gz

    Как я могу узнать, открыт ли порт TCP или нет?

    Как отслеживать во время выполнения символы загруженной разделяемой библиотеки?

    apache mod_security и производительность

    Проблемы с доступом к каталогам общего доступа CIFS

    Объединение файлов с использованием метода застежки-молнии / позднего слияния

    Linux и Unix - лучшая ОС в мире.