nicht angemeldet
Hallo Dennis,
find: WARNING: Hard link count is wrong for /: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.
Was ist damit gemeint?
Die Meldung sollte eigentlich nicht auftreten, die könnte auf Inkonsistenzen im Dateisystem hindeuten. Hast Du mal eine Dateisystemprüfung durchgeführt?
Was die Meldung genau bedeutet: Ein Dateisystem speichert Dateien in mindestens zwei verschiedenen Teilen: Zum einen als Eintrag im Verzeichnis, in dem sich die Datei befindet, dort steht mindetens der Name der Datei drin. Zum anderen werden die Daten separat abgelegt. Zusätzliche Informationen wie Besitzer, Rechte, Datum werden entweder im Verzeichnis abgespeichert oder an einem dritten Ort.
Bei FAT (DOS/Windows) sieht das ganze so aus: Alle Metainformationen zu einer Datei sind im Verzeichnis gespeichert, d.h. das Verzeichnis enthält Name, Datum, Attribute, etc. der Datei. Ferner enthält das Verzeichnis die Nummer des ersten Blocks der Datei. In einem extra reservierten Bereich des Dateisystems wird dann noch vermerkt, welches der nachfolgende Block zum ersten ist, dann wieder welches der nachfolgende zu dem ist usw. usf.
Bei typischen Linux-Dateisystemen sieht das dagegen so aus: Im Verzeichnis wird nur der Name und die sogenannte Inode-Nummer erwähnt. Zu jeder Datei gibt es dann eine sogenannte Inode, die dann die weiteren Informationen wie Besitzer, Rechte und Datum zu dieser Datei enthält sowie die Angabe, welche Blöcke die Datei belegt. Unter Linux ist es ferner möglich, dass auf eine Inode zwei Einträge in einem Verzeichnis zeigen. Wenn ich also einen Eintrag /a habe und einen Eintrag /b und beide zeigen auf die gleiche Inode, dann sind beide im Endeffekt die gleiche Datei. Das ganze nennt sich "Hard links". Man kann bei "Hard links" nicht auseinanderhalten, welches von beiden die ursprüngliche Datei ist, beide Einträge im Verzeichnis sind absolut äquivalent.
Hard links auf Verzeichnisse sind heutzutage (zumindest unter Linux) verboten, da zu viele Leute damit zuviel Mist angestellt haben (man kann damit prima Endlosschleifen und ähnliches basteln) - und man eigentlich nie einen sinnvollen Einsatzzweck dafür gefunden hat. Allerdings werden Hard Links auf Verzeichnisse durchaus noch intern verwendet. Es gibt ja in jedem Verzeichnis zwei besondere Verzeichnisse '.' und '..'. Unter DOS/Windows sind das wirklich nur symbolische Namen, die es NICHT gibt. Unter Linux dagegen sind '.' und '..' dagegen real existierende Einträge in *jedem* Verzeichnis, die nichts anderes als Hard links auf das eigene Verzeichnis bzw. das Elternverzeichnis sind.
Nun gibt es in jeder Inode noch einen sogenannten "Hard link count", der angibt, wie oft es Hard links auf eine Inode gibt. Denn wenn ich einen Verzeichniseintrag per »rm« lösche, dann lösche ich erst einmal nur den Eintrag, nicht die Inode. Dabei wird allerdings auch dieser Zähler in der Inode um 1 verringert. Sollte der Zähler in der Inode 0 erreicht haben, heißt das, die Inode wird nirgendwo mehr verwendet, d.h. es wurde der letzte Eintrag zu dieser Datei gelöscht, d.h. die ganze Datei kann verschwinden, dann wird auch die Inode gelöscht und die Blöcke wieder freigegeben, die die Datei enthielten.
Deine Meldnug besagt nun, dass der Zähler des Hauptverzeichnisses (/) nicht mit der Anzahl an Links, die es geben _müsste_, übereinstimmt. Das tritt unter Umständen bei Dateisystemen auf, die die Semantik mit . und .. nicht so umsetzen, d.h. bei FAT o.ä., wenn Du das unter Linux einbindest, da wäre das auch kein Problem. Bei einem Linux-Dateisystem, wie Du es für Dein Hauptverzeichnis / verwendest, sollte so etwas aber definitiv nicht auftreten; es gibt hierfür zwei Möglichkeiten:
* Das Dateisystem ist inkonsistent: dann solltest Du dringend eine
Überprüfung des Dateisystems durchführen.
* Der Dateisystemtreiber hat einen Bug: dann solltest Du dringend einen
neuen Kernel nutzen mit einer ausgebesserten Version des Dateisystem-
treibers, denn sonst könntest Du Daten verlieren.
Der Rest der Meldung (mit dem -noleaf und so) sagt nichts anders aus, als dass find erkannt hat, dass es da irgend ein Problem gibt und dass es eine Optimierung automatisch ausgeschaltet hat, die im Normalfall den Suchvorgang beschleunigt, wenn der Hard link count für Verzeichnisse stimmt.
Viele Grüße,
Christian
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." - Bjarne Stroustrup