Diskussion:Inode

message: Im Text steht, dass eine Inode alle Attribute enthält. Aber unter "gespeicherte Informationen" steht dann nichts mehr von den dateiattributen. Werden jetzt die Dateiattribute (bei FAT/NTFS: Schreibgeschützt, Versteckt, System, Archiv) in der Inode gespeichert oder wo anders? -MrBurns 08:34, 15. Mai 2006 (CEST)
replies: text: Das FAT-Dateisystem besitzt keine Inodes, nur Verzeichniseinträge. Diese enthalten bei FAT sowohl den Dateinamen als auch Metainformationen wie Dateiattribute, Änderungszeiten usw. Inode-basierte Dateisysteme (wie die meisten Unix-Dateisysteme) wiederum besitzen keine Dateiattribute, wie sie FAT besitzt, sondern Bits, die die Zugriffsrechte und den Dateityp (regulär, Verzeichnis, Gerätedatei, Socket, usw.) angeben. Diese sind am ehesten mit den Dateiattributen bei FAT vergleichbar. --RokerHRO 08:07, 16. Mai 2006 (CEST)
thread_title: Attribute

message: Falls die 12 direkten Blockadressen nicht ausreichen, gibt es afaik je einen Zeiger für ein-, zwei- und dreifach indirekt adressierte Blöcke. Also insgesamt 3 Zeiger in der Inode.
--84.56.10.253 10:59, 4. Jul 2006 (CEST)
thread_title:  Anzahl der Zeiger auf weitere Cluster 

message: Wenn ich mich nicht irre, stimmt das Bild nicht ganz. 
In der /fs/ext2/inode.c wird die Variable direct_blocks auf den Wert von EXT2_NDIR_BLOCKS gesetzt - dieser wird in /include/linux/ext2_fs.h mit 12 defniert. Also sollte es doch die direkten Blöcke 0 bis 11 statt nur bis 9 geben?
Achso... kurze ergänzung: Nachgeschlagen hab ich das alles direkt im Linuxkernel auf http://lxr.linux.no/linux/fs/ext2/inode.c#L186.
(unsignierter Beitrag offenbar von Thorsten.alge, 23.1.07)
:Habe den Text
::Diese Abbildung ist nicht ganz Korrekt. Es gibt 12 direkte Blöcke und nicht nur 10. Das war schon bei Unix System Rel. 4 im S5 Filesystem so und die Linux Kernel Quellen stellen das auch so dar.
:trotzdem entfernt, weil
:* er schlecht dargestellt wurde,
:* so etwas auf die Diskussionsseite gehört und
:* die offenbar korrekte Anzahl 12 (anstelle der im Bild dargestellten 10) ohnehin im Text steht.
:--Tobias 15:16, 27. Mai 2008 (CEST)
thread_title:  Fehler im Bild 

message: "Inode (oder I-Node) wird im Deutschen am besten als Informationsknoten oder Indexeintrag bezeichnet."
Das ist doch Nonsense, eine Gewaltübersetzung. Wenn jemand von "Informationsknoten" oder "Indexeintrag" redet, weiss kein Mensch, dass er einen Inode meint. Darum wir auch im Deutschen einfach von "Inode" gesprochen. Ich möchte diesen Satz gerne entfernen. --Oreg 13:50, 27. Jan. 2009 (CET)
replies: text: Die Uebersetzung von "Node" als "Knoten" sollte man m.E. schon reinbringen, das ist naemlich der Ursprung und ist auch nicht weit hergeholt, da werden die Dateien, Devices usw. "dran festgemacht". -- 194.8.205.234 00:17, 19. Dez. 2012 (CET)
thread_title:  Übersetzung 

message: Im Beitrag steht, dass die Größe einer Datei von der Blockgröße abhängt. Bei 1KB Blöcken sind Dateien bis 16GB möglich, bei 4KB Blöcken bis 2TB (bei 32 Bit Adressen = 4Byte).
Die 16GB kann ich nachvollziehen (Pro Adressblock gibt es 1024Byte/4Byte = 256 Adressen):
      12   (direkt)
    +256   (1-fach indirekt)
    +256^2 (2-fach indirekt)
    +256^3 (3-fach indirekt)
 =  16843020 Datenblöcke; Jeder Block hat 1KB => 16448MB => 16GB
Die 2TB kann ich nicht nachvollziehen (Pro Adressblock gibt es 4096Byte/4Byte = 1024 Adressen):
       12   (direkt)
    +1024   (1-fach indirekt)
    +1024^2 (2-fach indirekt)
    +1024^3 (3-fach indirekt)
 = 1074791436 Datenblöcke; Jeder Block hat 4KB => 4*1074791436KB => 4100 GB => 4TB
Ist nun der Artikel fehlerhaft, oder mein Rechenweg?
--84.145.112.214 12:22, 29. Mär. 2009 (CEST)
replies: text: Ich hab da auch Probleme das zu verstehen. Könnte jemand der davon mehr Ahnung hat das ganze verständlicher schreiben ? 178.4.156.218 13:15, 31. Okt. 2016 (CET)
thread_title:  Maximale Größe von Dateien 

message: Zum heute im Entwurf "geborenen" vorläufigen Satz 
Unter Windows verhält sich das Dateisystem NTFS ähnlich.
b.i.t.t.e ich um Kommentare durch jemanden, dem NTFS wenigstens annähernd bekannt ist:
[Meine] Primärfrage ist die Wortwahl "ähnlich" vs. "analog", aber DAVOR steht immer noch, ob's nicht möglich wäre [ES W.Ä.R.E!!!], den dzt. voll UNIX/ext2-bezogenen Artikel a.l.l.g.e.m.e.i.n zu halten: so etwa nutzt auch MacOS-X [wie auch immer man das schRei.i.i.bpt] in-etwa sowas. [w.] 18:39, 30. Mär. 2009 (CEST)
replies: text: Laut diesem Artikel  sind die File Records bei NTFS nicht das gleiche wie Unix Inodes. --Oreg 00:24, 31. Mär. 2009 (CEST)
replies: text: Danke für diesen Link, der mich betreffend möglicher OMA-Tauglichkeit einer allgemein gehaltenen Einleitung, oder sogar eines systemübergreifend formulierten Artikels, total ernüchtert hat: Bei der Suche nach Erklärung für hard links unter WinXP/NTFS war ich auf Erklärungen für die Linux-Ebene geraten, ohne dass mir der grundlegende Unterschied auffiel. Dazu kam's nicht zuletzt durch den ohnedies mehrfach kritisierte Artikel Harter Link, dessen Einleitung ausschließlich auf Inode verweist, ohne Windows zu erwähnen. Ich versuche noch eine entsprechende Nachbesserung meines gestrigen Edits, bevor ich wohl das Handtuch werfe um bei meinen Leisten weiter zu machen. [w.] 09:13, 31. Mär. 2009 (CEST)
thread_title: Unter Windows&c

message: In der begründeten Hoffnung, die Artikelversion vom 23. unter Berücksichtigung von Oregs Einwänden jetzt eindeutig verbessert zu haben, habe ich die letzte Version als "gesichtet" markiert. Gestrichen wurde insbesondere:
*..."ähnlich einem Primärschlüssel in einer Datenbank" aus der Einleitung. Dort erzeugt das bloß Verwirrung, dass es in die genauere Beschreibung hineinsoll bezweifle ich ebenfalls. 
*Die Anleitung zum Erstellen von Hardlinks -- war hier off-topic
*Die Erklärung für (...Hardlinks = Namen der Datei, das heißt Zahl der Verweise aus den Verzeichnissen auf die Datei, unter "Referenzzähler".
Mögliche Fehler, die irrtümlich entstanden/verblieben sein könnten:
*Alle Zahlenangaben wurden ungesichtet übernommen
*Inode ist ein Eintrag in einem Unix-Dateisystem OK?? 
*aufgrund meines Verständnisses des Artikels Unix-Dateirechte schiene es weit übersichtlicher, die ersten drei Listenpunkte für den Inhalt des Inodes zu einem einzigen zusammenzufassen:
*Zugriffsrechte (für Eigentümer, Gruppen und Sonstige). -- allerdings war ich dafür nicht mutig genug.
*"bis zu 12 Verweise..." ersetzt jetzt die Schwurbelkonstruktion mit "beziehungsweise" -- aber: stimmt das allgemein, oder bloß für ext2?
Fragen:
*Die Formulierungen "In den meisten Unix-Betriebssystemen werden Dateien nur über ihre Inodes aufgerufen." und "...Inhalt wird von den meisten heutigen Dateisystem-Implementierungen..." sind zu schwammig -- hier wäre wenigstens je eine Ausnahme zu nennen (ich nehme nehme an, es handelt sich um veraltete oder kleingestutzte Distributionen, die ohne Inodes auskommen?).
*Da sich lt. Artikel (weit unten) eine Liste aller nicht belegten Inodes erstellen lässt, scheint die maximale Anzahl möglicher Inodes fix vorgegeben -- falls ja, wäre ein Beispiel für diese Größe wünschenswert. Falls ich das falsch verstehe, wäre eine Erklärung angebracht, wie Inodes gebildet werden (entstehen) und wie es zu "nicht belegten" Inodes kommt.
*Die enWP bezeichnet Inodes als Datenstruktur, was ich aber nicht übernommen habe, da die deWP Datenstrukturen als "nicht nur durch ihre beinhalteten Daten charakterisiert" bezeichnet, was gem. dem Artikel Inode aber nicht zuzutreffen scheint, oder?
Gruß, [w.] 11:42, 31. Mär. 2009 (CEST)
thread_title: Mein letzter Edit

message: Der dateiname verweist auf ein inode. Und wo wird der dateiname gespeichert? Neoexpert 13:26, 1. Feb. 2011 (CET)
replies: text: Die Frage ist zwar schon etwas älter, ich habe die Beantwortung trotzdem mal dem Artikel hinzugefügt (Nach der Auflistung was ein Inode enthält). Milania (Diskussion) 20:45, 10. Sep. 2012 (CEST)
thread_title:  Wo wird denn nun der Dateiname gespeichert? 

message: Es fehlt jegliche Aussage zu Inodes und FAT-Dateisystemen. --Itu 09:27, 16. Sep. 2011 (CEST)
replies: text: Ich verstehe nicht ganz: Ist es nicht so, dass es bei FAT gar keine Inodes gibt? Warum sollte man das extra erwähnen? In den Amiga-Dateisystemen gibt es auch keine Inodes, sollen die dann auch noch hier rein? --PeterFrankfurt 01:36, 17. Sep. 2011 (CEST)
replies: text: Ich weiss jetzt nicht genau ob es bei FAT keine inodes gibt. Ich weiss aber dass ich bei meinem gemounteten USB-laufwerk mit FAT mit ls -i  genauso inodes angezeigt bekomme wie bei ext. --Itu 23:56, 17. Sep. 2011 (CEST)
replies: text: Im Artikel File Allocation Table finde ich jedenfalls keine Erwähnung von Inodes. --PeterFrankfurt 01:14, 18. Sep. 2011 (CEST)
thread_title:  FAT 

message: Was m.E. evtl. noch von Interesse waere (falls es nicht zu speziell ist, WP soll ja kein Lehrbuch sein) :
- Verzeichnisse sind auf vielen *ix-Filesystems nichts weiter als strukturierte Dateien und benoetigen daher (mindestens) eine Inode, waehrend sie z.B. auf FAT in einem separaten (relativ) geschuetzten Speicherbereich ausserhalb des eigentlichen Datenbereiches verwaltet werden.
- Verzeichnisse haben immer mindestens 2 Inodes, naemlich eine, die auf sie selbst verweist (".") und eine zum uebergeordneten Verzeichnis (".."). Der Inode-Zaehler wird beim "ls -l" auch vorn angezeigt, so dass man Dateien mit Hardlinks identifizieren kann. Ausnahme ist meines Wissens nur Root, bei dem beide Links auf die gleiche Verzeichnisdatei verweisen.
- Loescht man eine Inode (unlink), dann existiert die Datei weiter, ist aber nicht mehr zugreifbar. Loescht man die Inode eines Verzeichnisses zum uebergeordneten Verzeichnis, dann kann man sich unterhalb des Verzeichnisses so lange weiter bewegen, bis man einmal raus ist, dann kommt man nie wieder rein. Sviw. findet nur fsck solche Inkonsistenzen und ist in der Lage, sie zu bereinigen.
- Inodes (spezielle, z.B. Devices und Named Pipes, aber auch regulaere) koennen auf relativ niedriger Ebene mit mknod erzeugt werden. Leider sind alle 3 Erwaehnungen des mknod-Kommandos in der deutschen WP diesbezueglich fehlerhaft oder unvollstaendig, hier waere m.E. ein guter Ort, das mal zurechtzuruecken.
- Die maximale Anzahl der Knoten je log. Platte ist (zumindest bei aelteren Systemen) bei der Kernelgenerierung einzustellen, die Inode-Belegung wird neben dem Plattenplatz auch beim Kommando "df" angezeigt. Ist das Limit erreicht, kann man keine weiteren Dateien anlegen, auch wenn noch viel Platz auf der Partition ist.
Ich kenne nur aeltere Filesystems und bin auch kein "Systemer", daher bringe ich mein 2/3-Wissen erstmal nur hier ein -- 194.8.205.234 00:49, 19. Dez. 2012 (CET)
thread_title:  Verzeichnisse und andere Knotentypen unter *ix 

message: Werter Michael »Michi« Schönitzer,
stilistisch anstößig ist im Abschnitt »Verzeichnisse« die Bearbeitung des Satzes
:»Für jedes Verzeichnis existieren immer die Einträge „.“ für das aktuelle und „..“ für das übergeordnete Verzeichnis.« (2. April 2014 09:57, Grixlkraxl)
Zugrunde liegt der missglückten Neufassung 
:»Für jedes Verzeichnis existieren immer die Einträge . als Verweise auf das aktuelle und .. für das übergeordnete Verzeichnis.« (16. Juni 2015 18:11, MichaelSchoenitzer)
die (inhaltlich wie formal) parallel gebaute Parataxe
:»der Eintrag a als Verweis auf x und der Eintrag b als Verweis auf y«.
Beide Satzteile können aufgrund gemeinsamer Satzteilglieder zusammengezogen werden zu:
:»die Einträge a und b als Verweise auf x bzw. y«. 
Die Konjunktion beziehungsweise bedeutet in dieser Konstruktion so viel wie und im anderen Fall[e]. Beispiel: »Der Träger des Gelben Trikots darf sich in Paris über 450.000 Euro freuen. Für die Plätze zwei und drei werden noch 200.000 bzw. 100.000 Euro ausgeschüttet.« (Quelle: SID)
Für den überarbeiteten Satz ergibt sich mithin: 
:»Für jedes Verzeichnis existieren immer die Einträge . und .. als Verweise auf das aktuelle bzw. übergeordnete Verzeichnis.«
MfG Thorsten, Hamburg – PunPunKomStr 10:34, 17. Sep. 2015 (CEST)
thread_title:  Satzbau 

message: Im Abschnitt Praxis würde ich gerne die Bedeutung der Befehle stat und find für das Arbeiten mit Inodes hervorheben und folgendes Beispiel einbauen:
# Wir legen die Datei /tmp/meine_testdatei.txt an. 
echo "Ich liebe Wikipedia." > /tmp/testdatei.txt
# Wir ermitteln den Inode der neuen Datei indem wir die Ausgabe 
# des Befehls stat in der Variablen 'my_inode' speichern
my_inode=$( stat --printf="%i" /tmp/testdatei.txt )
# Wir geben den ermittelten Wert der Inode aus. 
echo "Für /tmp/testdatei.txt wurde der Inode ${my_inode} ermittelt."
# Wir legen den Hardlink /tmp/hardlink_auf_testdatei.txt an
ln /tmp/testdatei.txt /tmp/hardlink_auf_testdatei.txt
# wir listen alle Dateien mit dem oben ermittelten Inode.
# Mögliche Fehlermeldungen wie "Permission denied" werden 
# nach /dev/null umgeleitet.
echo "Gefundene Dateien mit Inode ${my_inode}:"
find /tmp -xdev -inum ${my_inode} -print 2>/dev/null
# Wir löschen die ursprüngliche Datei. 
# Der Inhalt bleibt im Hardlink erhalten! 
rm /tmp/testdatei.txt
# Wir listen nochmal alle Dateien mit dem Inode my_inode. 
# Diesmal verwneden wir den Befehl ls und Filtern mit grep.
# Es existiert nur noch eine Datei mit dem Inode! 
echo "Nochmal eine Liste aller gefundenen Dateien mit Inode ${my_inode}"
echo "(inzwischen wurde /tmp/testdatei.txt gelöscht):"
ls -i /tmp | grep "^ *${my_inode} "
# Wir geben den Inhalt von /tmp/hardlink_auf_testdatei.txt aus 
# und sehen das er identisch mit dem der gelöschten Datei ist. 
echo "Inhalt von /tmp/hardlink_auf_testdatei.txt:"
cat /tmp/hardlink_auf_testdatei.txt
# Wir räumen auf und löschen auch /tmp/hardlink_auf_testdatei.txt.
rm /tmp/hardlink_auf_testdatei.txt
 
--TapTun (Diskussion) 16:33, 7. Mai 2023 (CEST)
thread_title:  Bedeutung von "stat" und "find" für das Arbeiten mit Inodes