Habe gerade angefangen, ein bisschen über das Linux-Dateisystem zu lesen. An mehreren Stellen fand ich Zitate wie dieses:
Unix-Verzeichnisse sind Listen von Assoziationsstrukturen, von denen jede einen Dateinamen und eine Inode-Nummer enthält.
Ich hatte also erwartet, dass jedes Verzeichnis die Namen der darin enthaltenen Dateien enthält, wobei jede Datei einem Inode zugeordnet ist. Aber wenn ich das vim directory_namein Ubuntu mache, bekomme ich so etwas:
" ============================================================================
" 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
Ich habe erwartet, neben jedem Dateinamen eine Inode-Nummer zu sehen. Warum ist das nicht der Fall?
Antwort1
In diesem Zitat geht es darum, wie Unix-Dateisysteme (logischerweise – die tatsächlichen Strukturen sind heutzutage oft ganz anders) funktionieren. Und Sie können die Inode-Nummern beispielsweise mit dem -iFlag to sehen 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
Die Nummer links ist der Inode. Und wenn ich ausführe ln b c(einen Hardlink erstellen), dann:
$ 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
Die Berechtigungen und die Größe sind Teil des Inodes, nicht des Verzeichnisses. Das lässt sich leicht daran erkennen, was danach passiert 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
beide bund cgeändert, weil sie denselben Inode teilen.
Der Kernel stellt das Dateisystem dem Benutzerbereich jedoch nur über eine wohldefinierte API zur Verfügung (mit Ausnahme der Rohgeräte wie /dev/sda1). Er gibt dem Benutzerbereich Zugriff auf eine Reihe von Systemaufrufen, um Dinge wie das Erstellen und Entfernen von Links, das Ändern von Berechtigungen, das Lesen und Schreiben in Dateien, das Umbenennen usw. durchzuführen. Er stellt die rohen, zugrunde liegenden Datenstrukturen des Dateisystems dem Benutzerbereich nicht zur Verfügung. Dafür gibt es eine Reihe guter Gründe: Er ermöglicht Netzwerkdateisysteme, er bedeutet, dass der Kernel Berechtigungen erzwingen und die Datenstrukturen des Dateisystems korrekt halten kann, er bedeutet, dass Sie verschiedene Dateisysteme (mit unterschiedlichen Datenstrukturen) verwenden können, ohne den Benutzerbereich ändern zu müssen.
Im Grunde genommen vim dirwird Ihnen also nur eine Verzeichnisliste angezeigt – mehr oder weniger genau wie ls. Dies geschieht über ein Vim-Modul namens Netrw, wie oben angegeben (versuchen Sie es :help netrwin Vim). Sie können die zugrunde liegenden Datenstrukturen des Dateisystems nicht wirklich bearbeiten.
Antwort2
Ein Verzeichnis ist semantisch gesehen eine Abbildung von Dateinamen auf Inodes. So ist die Verzeichnisbaumabstraktion aufgebaut, die der Schnittstelle zwischen Anwendungen und Dateisystemen entspricht. Anwendungen können Dateien nach Namen benennen und die Liste der Dateien in einem Verzeichnis auflisten, und jede Datei hat einen eindeutigen Bezeichner, der als „Inode“ bezeichnet wird.
Wie diese Semantik implementiert wird, hängt vom Dateisystemtyp ab. Es hängt von jedem Dateisystem ab, wie das Verzeichnis codiert wird. In den meisten Unix-Dateisystemen ist ein Verzeichnis eine Zuordnung von Dateinamen zu Inode-Nummern, und es gibt eine separate Tabelle, die Inode-Nummern zu Inode-Daten zuordnet. (Die Inode-Daten enthalten Dateimetadaten wie Berechtigungen und Zeitstempel, den Speicherort des Dateiinhalts usw.) Die Zuordnung kann eine Liste, eine Hash-Tabelle, ein Baum usw. sein.
Mit Vim können Sie diese Zuordnung nicht sehen. Vim zeigt den Speicherbereich, der das Verzeichnis darstellt, nicht an. Linux, wie viele andere moderne Unix-Systeme, ermöglicht es Anwendungen nicht, die Verzeichnisdarstellung direkt zu sehen. Verzeichnisse verhalten sich wie normale Dateien, was ihre Verzeichniseinträge und Metadaten betrifft, aber nicht, was ihren Inhalt betrifft. Anwendungen lesen aus normalen Dateien mit Systemaufrufen wie open, read, write, close; für Verzeichnisse gibt es andere Systemaufrufe: opendir, readdir, closedir, und das Ändern eines Verzeichnisses erfolgt durch Erstellen, Verschieben und Löschen von Dateien. Eine Anwendung wie catverwendet open, read, closeum den Inhalt einer Datei zu lesen; eine Anwendung wie lsverwendet opendir, readdir, closedirum den Inhalt eines Verzeichnisses zu lesen. Vim funktioniert normalerweise wie, catum den Inhalt einer Datei zu lesen, aber wenn Sie es auffordern, ein Verzeichnis zu öffnen, funktioniert es wie lsund druckt die Daten in schön formatierter Weise aus.
Wenn Sie sehen möchten, wie ein Verzeichnis unter der Haube aussieht, können Sie ein Tool wie debugfsfür ext2/ext3/ext4 verwenden. Stellen Sie sicher, dass Sie nichts ändern! Ein Tool wie debugfsumgeht das Dateisystem und kann es vollständig zerstören. ext2/ext3/ext4 debugfsist sicher, da es sich im schreibgeschützten Modus befindet, sofern Sie das Schreiben nicht ausdrücklich über eine Befehlszeilenoption zulassen.
# debugfs /dev/root
debugfs 1.42.12 (29-Aug-2014)
debugfs: dump / /tmp/root.bin
debugfs: quit
# od -t x1 /tmp/root.bin
Sie sehen die Namen der Verzeichniseinträge inmitten /einer Reihe anderer Zeichen, von denen einige nicht druckbar sind. Um sie zu verstehen, müssen Sie die Details des Dateisystemformats kennen.
Antwort3
Ich vermute, Sie lesen eine wirklich sehr alte Darstellung der Funktionsweise des Unix-Dateisystems. Was Sie beschreiben, galt in den späten 1970er Jahren oder so, aber für moderne Dateisysteme gilt es nicht mehr.
Auf vielen modernen Plattformen sind mehrere Dateisysteme im allgemeinen Gebrauch und jedes davon verbirgt seine internen Komponenten vor dem Benutzerbereich. Sie können herausfinden, wie sie aussehen und mit ihnen herumspielen, aber wenn Sie sich nicht auf das Entwerfen von Dateisystemen spezialisieren möchten, ist es vielleicht besser, einfach darauf zu vertrauen, dass der Autor des Buches Ihnen genug vermittelt, um ein grundlegendes Verständnis des Designs zu erlangen, ohne zu sehr ins Detail zu gehen (einige davon werden ohnehin veraltet sein, wenn Sie es wieder brauchen).