staging.inyokaproject.org

BillMaier schrieb:

für einen Einsteiger leichter verständlich ist als eine kurze Einführung in den Begriff inode.

Ich habe nach wie vor nichts gegen die direkte Verwendung von "Inode" (und auf den ja einfach verlinkt werden kann). Wir befinden uns hier ja nicht mehr in einem Bereich, der jeden DAU überhaupt interessiert und irgendwie mit Krücken zugänglich gemacht werden soll. Deshalb befürworte ich hier kompromisslose Korrektheit gegenüber Leichtkost-Krücken.

... und ich denke, man kann dem Leser durchaus ein zweimaliges Lesen zumuten, um ihn erst mal aus der weit verbreiteten Fehldeutung zu befreien, dass ein Hardlink etwas Besonderes/Anderes im Vergleich zu einem normalen Verzeichniseintrag ist. Damit wird dann auch klar, warum er mit ls -l nicht so ohne weiteres erkennbar ist und dass der Vergleich von Hard- mit Softlink genaugenommen genauso schräg ist, wie der von Gebäude mit Museum.

-force entfernt nicht das ZIEL (die Datei), sondern die vorhandene Verknüpfung bzw. den mehrfachen Verzeichniseintrag (Hardlink).

Ja, ihr habt beide recht und im Normalfall bin ich auch für absolute Korrektheit, aber dann müsste man abgesehen von inodes auch noch korrigieren & erklären wieso eine Datei nicht wirklich gelöscht ist auch wenn man sie "gelöscht hat" und kein Hardlink mehr vorhanden ist bzw. wieso/wie diese wiederhergestellt werden kann und dann landen wir auch irgendwann bei den Unterschieden von SSDs zu HDDs usw...

Um ehrlich zu sein, selbst ich hab mir jetzt schon den Vorschlag mehr als einmal durchlesen müssen...

Ebenfalls ein komplett anderer Ansatz:
Da mehr oder weniger alle Varianten technisch gesehen sehr verkürzt bis inkorrekt sind und auch das Vokabular nicht einwandfrei ist, alleine um den Artikel allgemeinverständlich zu halten und nicht in zig "Sub-Erklärungen" unterzugehen... wie wäre eine Art "Disclaimer" um genau das anzuzeigen?
Also quasi am Anfang eine "Hinweis-" oder "Achtung-Box", dass das technisch keine akkurate Aufarbeitung/Erklärung der Sachverhalts ist um eine einfache allgemeine Verständlichkeit sicherzustellen bzw. zu ermöglichen. - Die könnte man dann ja auch mit Weiterführenden Fachvokabeln und Links ausstatten... oder auf einen "aufmagazinierten" Links-Bereich verweisen.

UlfZibis schrieb:

Wenn letzterer, z.B. durch Löschen des letzten Hardlinks (auf einen Inode), verschwindet, wird der Softlink ungültig.

Wenn ich die Aussage richtig verstanden habe, stimmt das aber auch nicht ganz: Der Softlink wird auch schon ungültig, wenn der eine "Ziel-Hardlink" gelöscht wurde, auch wenn "die physische Datei" mit zig anderen Hardlinks noch vorhanden ist.

Auch das Ersetzen von "diese" durch "die Originaldatei" trägt eher zur Verwirrung bei, denn der Leser fragt sich dann, was die "Zieldatei" von der "Originaldatei" unterscheidet.

Ja, das habe ich mir auch kurz gedacht, aber im selben Satz wurde "Originaldatei" vorhin auch schon verwendet und deswegen hatte ich keine Skrupel mehr das zu ändern... Ich werde mir eine Verbesserung der Passage überlegen.

Hm, das Thema des Artikels ist ln, und nicht Verknüpfungen. Die einfachste Form, ln DATEI, erzeugt einfach nur einen normalen Verzeichnis-Eintrag, sonst nichts. Dass man dafür auch den Begriff "Hardlink" verwendet, wenn er mehrfach vorkommt, ist m.E. ein Nebenthema. Der Abschnitt "Hardlinks" entspricht damit schon dem "Disclaimer", der gerne technisch korrekt und notfalls unbequem zu Lesen sein darf. Erst unter der Option -s passiert etwas "besonderes" ...

UlfZibis schrieb:

-force entfernt nicht das ZIEL (die Datei), sondern die vorhandene Verknüpfung bzw. den mehrfachen Verzeichniseintrag (Hardlink).

Oder genau genommen wird nicht entfernt, sondern überschrieben.

UlfZibis schrieb:

Hm, das Thema des Artikels ist ln, und nicht Verknüpfungen. Die einfachste Form, ln DATEI, erzeugt einfach nur einen normalen Verzeichnis-Eintrag, sonst nichts. Dass man dafür auch den Begriff "Hardlink" verwendet, wenn er mehrfach vorkommt, ist m.E. ein Nebenthema. Der Abschnitt "Hardlinks" entspricht damit schon dem "Disclaimer", der gerne technisch korrekt und notfalls unbequem zu Lesen sein darf. Erst unter der Option -s passiert etwas "besonderes" ...

Darf ich hier mal intervenieren? Ja, du hast technisch recht. Wir sollten aber schauen, dass der Artikel allgemeinverständlich bleibt und sich am Anwender orientiert. Und der fragt "wo ist der Unterschied zwischen Symlinks und Hardlinks?" und "wie wende ich das sinnvoll an?" Der Schwerpunkt des Artikels liegt tatsächlich auf den Verknüpfungen (siehe auch den aktuellen Artikel im Wiki ) - das hat DJCrashdummy nicht neu erfunden und das finde ich ok so.

Ich wäre dafür, dass wir den Artikel wieder Richtung Wiki kriegen. Was wäre dazu aus Eurer Sicht (inhaltlich) noch unbedingt notwendig? Aus meiner Sicht könnte die "Verschlimmbesserung" (sorry für das Wort, ich beziehe mich damit auf die Diskussion weiter oben) mit dem "physikalischen" Bezug wieder zurück. Vielleicht findet man ja einmalig eine Formulierung wie "...in der Regel auf den physikalische Speicherort zeigt (es können aber auch sockets oder device-Dateien sein)" - nur mal so ins Blaue. Ansonsten gibt es noch Kleinigkeiten wie

UlfZibis schrieb:

-force entfernt nicht das ZIEL (die Datei), sondern die vorhandene Verknüpfung bzw. den mehrfachen Verzeichniseintrag (Hardlink).

Oder genau genommen wird nicht entfernt, sondern überschrieben.

Die könnten wir ja gemeinsam richtig stellen. Und wenn ein Artikel aus der Baustelle draußen ist, kann man ja Kleinigkeiten/Formulierungen immer noch optimieren.

Wäre das ok für euch?

BillMaier schrieb:

Aus meiner Sicht könnte die "Verschlimmbesserung" (sorry für das Wort, ich beziehe mich damit auf die Diskussion weiter oben) mit dem "physikalischen" Bezug wieder zurück.

Unbedingt!

Vielleicht findet man ja einmalig eine Formulierung wie "...in der Regel auf den physikalische Speicherort zeigt (es können aber auch sockets oder device-Dateien sein)" - nur mal so ins Blaue.

Ich zweifle sehr, ob der bisherige Text mit so einem Einschub dann immer noch flüssiger zu lesen ist, wie mein von Euch so bemängelter Vorschlag. Außerdem ist er technisch immer noch falsch, denn es gibt noch mehr Typen von Verzeichniseinträgen außer für sockets und devices, z.B. /proc-Einträge und vor allem die Symlink-Einträge.
Hier noch ein technisch korrekter (hoffentlich) Vorschlag, der vielleicht besser zu lesen ist:

Ein Hardlink ist eine technische Bezeichnung für den gewöhnlichen Eintrag im Verzeichnis eines Dateisystem, der im Regelfall auf den Speicherplatz einer Datei verweist. Er wird gerne verwendet, um die Fähigkeit eines Dateisystem hervorzuheben, mehrere Verzeichniseinträge für dasselbe Objekt zuzulassen.

Ich denke, wir sollten auch genau zwischen Einträgen im Dateiverzeichnis und im Dateisystem unterscheiden, denn in letzterem gibt es auch Einträge, die nicht im Verzeichnis stehen, z.B. die FAT, der Bootsektor, das Verzeichnis selbst ...

Das Argument bzgl. der Zirkelschlüsse würde ich streichen, das es nicht schlüssig ist. Mit . und .. gibt es ja Mehrfach-Hardlinks und das Problem mit den Zirkelschlüssen, was ich im Zusammenhang mit Hardlinks auch nicht verstehe, gibt es noch gravierender mit den Softlinks.

Die könnten wir ja gemeinsam richtig stellen. Und wenn ein Artikel aus der Baustelle draußen ist, kann man ja Kleinigkeiten/Formulierungen immer noch optimieren.

Meinst Du das ernst, es dem Zufall überlassen zu wollen, ob jemand mal Lust dazu hat? Bei der Kleinigkeit handelt es sich nicht um eine Formulierungsvariaton, sondern um eine echten Fehler. Ich hab's nicht selber gemacht, weil ich die Eingriffe DJCrashdummy überlassen wollte und auch erst mal ein Feedback dazu haben wollte, evtl. irre ich mich ja sogar.

Wäre das ok für euch?

Von mir aus könnt Ihr schreiben, was ihr wollt, ich habe ja mittlerweile verstanden, was ein Hardlink ist, wozu die bisherige Formulierung nur umständlich zu beigetragen hat. Wollte einfach nur zur Verbesserung des Verständnisses aus der Sicht eines noch nicht Verstehenden beitragen.

UlfZibis schrieb:

BillMaier schrieb:

Die könnten wir ja gemeinsam richtig stellen. Und wenn ein Artikel aus der Baustelle draußen ist, kann man ja Kleinigkeiten/Formulierungen immer noch optimieren.

Meinst Du das ernst, es dem Zufall überlassen zu wollen, ob jemand mal Lust dazu hat?

Ich habe keine Ahnung, wie du zu diesem Schluss kommst. Ich meine damit, dass ein Artikel auch im Wiki (ohne Baustelle) weiter optimiert werden kann. Ob ein Artikel überhaupt angepasst wird, hängt tatsächlich von der Bereitschaft (du nennst es Lust) der community ab. Die Zufallsdiskussion ist aber eine andere und OT.

Bei der Kleinigkeit handelt es sich nicht um eine Formulierungsvariaton, sondern um eine echten Fehler.

Dann sollten die korrigiert werden.

Ich hab's nicht selber gemacht, weil ich die Eingriffe DJCrashdummy überlassen wollte und auch erst mal ein Feedback dazu haben wollte, evtl. irre ich mich ja sogar.

Passt. Ist nur die Frage, ob DJCrashdummy das auch so sieht oder vll. sogar dankbar ist, wenn wir im Artikel selbst weiter machen.

Wäre das ok für euch?

Von mir aus könnt Ihr schreiben, was ihr wollt,

Na toll, so viel zum Zufall und zur Lust 🙄

Wollte einfach nur zur Verbesserung des Verständnisses aus der Sicht eines noch nicht Verstehenden beitragen.

Aber bitte doch!

UlfZibis schrieb:

Wollte einfach nur zur Verbesserung des Verständnisses aus der Sicht eines noch nicht Verstehenden beitragen.

Ich glaube eher, dass du zur technischen Korrektheit beiträgst.

Also ich habe teilweise Leseproben va. zum theoretischen Verständnis einem sogenannten DAU vorgelegt... und die (verkürzte) Conclusio war, das jede "zusätzliche Ebene" - va. wenn sie der User nicht "sieht/braucht" - potenziert fast die Komplexität des Themas bzw. des Artikels und erschwert dementsprechend das (grundlegende) Verständnis beträchtlich.

BillMaier schrieb:

Wir sollten aber schauen, dass der Artikel allgemeinverständlich bleibt und sich am Anwender orientiert. Und der fragt "wo ist der Unterschied zwischen Symlinks und Hardlinks?" und "wie wende ich das sinnvoll an?"

Da stimme ich absolut zu!
Um ehrlich zu sein: Als Einsteiger habe ich früher immer ins Ubuntuusers-Wiki geschaut, wenn ich komplett neu bei einem Thema war, um einen generellen Überblick zu bekommen (auch weil leichter verständlich in deutsch) und schnell Ergebnisse zu erzielen. Für den technischen Hintergrund landete und lande ich noch immer im Normalfall bei anderen (üblicher weise englischsprachigen) Seiten.

BillMaier schrieb:

Aus meiner Sicht könnte die "Verschlimmbesserung" (...) mit dem "physikalischen" Bezug wieder zurück.

"physikalisch" ist weg, aber ob es dadurch einfacher verständlich wird, ist fraglich. - Ja, ich weiß, dafür ist es technisch nicht mehr komplett falsch.
Sinn und Zweck dieser Formulierung war zu verdeutlichen, dass es einen Unterschied zwischen Pfad und tatsächlichem Speicherplatz einer Datei gibt! - Das ist erschreckender Weise den wenigsten DAUs klar... die glauben das was sie sehen (Ordner mit Dateien) ist genau so auf dem Datenträger organisiert.
–> Die Formulierung mit "tatsächlichem Speicherplatz" fiel mir erst während diesem Posting ein... ich weiß, ihr werdet immer noch Bauchweh dabei haben, aber zumindest etwas besser?

UlfZibis schrieb:

Hier noch ein technisch korrekter (hoffentlich) Vorschlag, der vielleicht besser zu lesen ist:

Ein Hardlink ist eine technische Bezeichnung für den gewöhnlichen Eintrag im Verzeichnis eines Dateisystem, der im Regelfall auf den Speicherplatz einer Datei verweist. Er wird gerne verwendet, um die Fähigkeit eines Dateisystem hervorzuheben, mehrere Verzeichniseinträge für dasselbe Objekt zuzulassen.

Der Vorschlag gefällt mir schon besser, weil er viel leichter zu lesen ist. Aber ob er die Verständlichkeit für DAUs verbessert bin ich mir nach wie vor nicht sicher...

UlfZibis schrieb:

UlfZibis schrieb:

-force entfernt nicht das ZIEL (die Datei), sondern die vorhandene Verknüpfung bzw. den mehrfachen Verzeichniseintrag (Hardlink).

Oder genau genommen wird nicht entfernt, sondern überschrieben.

em... daran habe ich absolut nichts geändert!
und noch dazu steht das genau so in der --help:

-f, --force: Vorhandene Ziele entfernen.

und auch die man-page sagt für mich das gleiche (auf englisch):

-f, --force: remove existing destination files

UlfZibis schrieb:

Ich hab's nicht selber gemacht, weil ich die Eingriffe DJCrashdummy überlassen wollte und auch erst mal ein Feedback dazu haben wollte, evtl. irre ich mich ja sogar.

Vielen Dank für die Rücksicht, das weiß ich zu schätzen! - Andererseits kann ich keinen Anspruch darauf stellen, weil das nicht "mein" Artikel ist, wie kein Wiki-Artikel "jemandem gehört". Aber auch im weitesten Sinne stammt der Großteil nicht von mir, sondern ich habe nur eine Reorganisation/Neuanordnung gestartet, weil es IMHO endgültig unübersichtlich bis teilweise sogar konfus geworden ist. - Was natürlich auch die Verständlichkeit eines Themas negativ beeinflusst.

BillMaier schrieb:

Ist nur die Frage, ob DJCrashdummy das auch so sieht oder vll. sogar dankbar ist, wenn wir im Artikel selbst weiter machen.

Um es anders auszudrücken und eine "Endlos-Baustelle" zu vermeiden: Meiner Meinung nach ist die Reorganisation des bestehenden Artikels (mit kleinen Ergänzungen & Korrekturen) abgeschlossen, wofür diese Baustelle auch gedacht war. IMHO kann somit der Artikel gerne so bleiben und auch das "Original" ersetzen, da ich auch keine signifikanten Verschlechterungen ausmachen kann.
–> Größere thematische und technische Änderungen können und sollten in einer anderen Baustelle gerne gemeinschaftlich gelöst werden. (Bei der Gelegenheit möchte ich aber auch gleich anmerken, dass ich mich da kaum federführend beteiligen werde, da schon die Reorganisation für mich zeitlich nur relativ knapp zu schaffen war.)

DJCrashdummy schrieb:

"physikalisch" ist weg, aber ob es dadurch einfacher verständlich wird, ist fraglich. - Ja, ich weiß, dafür ist es technisch nicht mehr komplett falsch.
Sinn und Zweck dieser Formulierung war zu verdeutlichen, dass es einen Unterschied zwischen Pfad und tatsächlichem Speicherplatz einer Datei gibt! - Das ist erschreckender Weise den wenigsten DAUs klar... die glauben das was sie sehen (Ordner mit Dateien) ist genau so auf dem Datenträger organisiert.
–> Die Formulierung mit "tatsächlichem Speicherplatz" fiel mir erst während diesem Posting ein... ich weiß, ihr werdet immer noch Bauchweh dabei haben, aber zumindest etwas besser?

Aus meiner Sicht nicht nur etwas besser, sondern wirklich sehr gelungen. 👍

Mein Zugang zu diesem Artikel kam darüber, dass ich einen Befehl suchte, der mir die Hardlinks einer Datei auflistet. Dabei zeigte sich, dass es im ganzen Wiki zum Thema Hardlinls nur diesen Abschnitt unter ln gibt, und ich als "Nicht-DAU" von dessen Informationsgehalt und Ungenauigkeit enttäuscht war. So hatte ich dann damals zumindest die fehlenden Befehle ergänzt.

Ich bezweifle, dass ein DAU, so wie Du ihn oben beschreibst, der nicht mal den Unterschied zwischen Pfad und Speicherplatz einer Datei nachvollziehen kann, überhaupt jemals in die Verlegenheit kommt, sich mit ln oder gar Hardlinks auseinanderzusetzen. Ich glaube, nur "Experten" interessiert dieses Thema, und denen sollte man, denke ich, technische Korrektheit liefern, und vor allem, wenn dies die einzige Stelle zum Thema im Wiki ist. Von daher fände ich es auch nicht übertrieben, die beiden Abschnitte, Hardlinks und Softlinks, in eine Expertenbox zu packen ... vielleicht sogar den ganzen Artikel so zu kennzeichnen.

UlfZibis schrieb:

Hier noch ein technisch korrekter (hoffentlich) Vorschlag, der vielleicht besser zu lesen ist:

Ein Hardlink ist eine technische Bezeichnung für den gewöhnlichen Eintrag im Verzeichnis eines Dateisystem, der im Regelfall auf den tatsächlichen Speicherplatz einer Datei verweist. Sie wird gerne verwendet, um die Fähigkeit eines Dateisystem hervorzuheben, mehrere Verzeichniseinträge für dasselbe Objekt zu verwalten.

Der Vorschlag gefällt mir schon besser, weil er viel leichter zu lesen ist. Aber ob er die Verständlichkeit für DAUs verbessert bin ich mir nach wie vor nicht sicher...

Der erste Satz (oben nochmal korrigiert) ist ja quasi gleich dem existierenden, nur dass er "einfach ... ein Name" durch "eine technische Bezeichnung" ersetzt, was ich viel zutreffender und erklärender finde. Der zweite Satz (auch nochmal korrigiert) dient eher dem "Nicht-DAU", den die Details interessieren, wie mehrere andere Sätze in diesem Abschnitt auch.
Wie gesagt, DAUs tangiert IMHO weder die existierende Formulierung, noch meine.
Auch auf Wikipedia, was ja auch für DAUs geschrieben wird, ist eine ähnliche Erklärung wie meine zu finden.
Um das mit dem Regelfall zu sparen könnte man auch kurz schreiben: ..., der auf die tatsächlichen Daten einer Datei verweist. Da sind dann die Metadaten und der eigentliche Inhalt mit drin.

UlfZibis schrieb:

UlfZibis schrieb:

-force entfernt nicht das ZIEL (die Datei), sondern die vorhandene Verknüpfung bzw. den mehrfachen Verzeichniseintrag (Hardlink).

Oder genau genommen wird nicht entfernt, sondern überschrieben.

em... daran habe ich absolut nichts geändert!
und noch dazu steht das genau so in der --help:

-f, --force: Vorhandene Ziele entfernen.

und auch die man-page sagt für mich das gleiche (auf englisch):

-f, --force: remove existing destination files

Diese Erklärung ist in der Tat unglücklich und verwirrend. Mit Ziel ist da wohl das Resultat des Befehls ln gemeint, also die Verknüpfung selbst, und nicht das Ziel dieser. Wenn im Beispiel-Befehl ZIEL als die zu verknüpfende Originaldatei auftaucht, wird der Leser wohl eher letzteres damit assoziieren. Die jetzige Erklärung, verleitet zu der Annahme, dass die Originaldatei gelöscht würde, was eben nicht stimmt. Wäre ja schlimm, wenn -force mal eben ZIEL ~/Dokumente/Rechnungen/ komplett löschen würde, falls der schon vorhandene VERKNÜPFUNGSNAME z.B. ~/Erledigen/ dorthin zeigen würde.
Wenn allerdings der VERKNÜPFUNGSNAMEs einer existierenden normalen Datei entspricht, wird mit -force tatsächlich die vorhandene Datei gelöscht (also VERKNÜPFUNGSNAME und nicht ZIEL) und ein gleichnamiger Link erzeugt. Das geschieht aber nur bei einer Datei, bei einem Verzeichnis erscheint trotz -force: ln: Erledigen: das Überschreiben des Verzeichnisses ist nicht möglich
Es ist also auch noch kompliziert!

UlfZibis schrieb:

Das Argument bzgl. der Zirkelschlüsse würde ich streichen, das es nicht schlüssig ist. Mit . und .. gibt es ja Mehrfach-Hardlinks und das Problem mit den Zirkelschlüssen, was ich im Zusammenhang mit Hardlinks auch nicht verstehe, gibt es noch gravierender mit den Softlinks.

Hier steht, dass Hardlinks auf Verzeichnisse wegen möglicher Konsistenzprobleme "verboten" sind. Das erscheint mir zutreffender als Grund dafür. Was die damit aber genau meinen, steht da leider auch nicht.

EDIT: Hab' nun den Grund im englischen Wikipedia gefunden. Da steht zwar auch was von Zirkelschlüssen (ohne nähere Erläuterung des dabei auftauchenden Problems), die aber zu beherrschen sein müssten, genauso wie bei den Softlinks, aber das Konsistenzproblem besteht darin, dass wenn es mehrere normale Verweise auf ein Verzeichnis gibt, die Auflösung von .. nicht mehr eindeutig ist. Ich frage mich allerdings nun, wie das bei Dateien geht, einen Elternpfad zu bestimmen, wenn es da mehrere gibt.

DJCrashdummy schrieb:

Meiner Meinung nach ist die Reorganisation des bestehenden Artikels (mit kleinen Ergänzungen & Korrekturen) abgeschlossen, wofür diese Baustelle auch gedacht war. IMHO kann somit der Artikel gerne so bleiben und auch das "Original" ersetzen, da ich auch keine signifikanten Verschlechterungen ausmachen kann.
–> Größere thematische und technische Änderungen können und sollten in einer anderen Baustelle gerne gemeinschaftlich gelöst werden. (Bei der Gelegenheit möchte ich aber auch gleich anmerken, dass ich mich da kaum federführend beteiligen werde, da schon die Reorganisation für mich zeitlich nur relativ knapp zu schaffen war.)

Letzte Chance für Korrekturen in der Baustelle - ich werde den Artikel dann im Lauf der Woche (nach einer letzten Korrektur) zurück ins Wiki schieben.

Gruß BillMaier

Hallo,

Artikel ist mit ein paar Minikorrekturen wieder im Wiki. Danke für's überarbeiten.

Gruß, noisefloor

Hallo und danke fürs Verschieben.

BillMaier schrieb:

ich werde den Artikel dann im Lauf der Woche (nach einer letzten Korrektur) zurück ins Wiki schieben.

Ich hatte die Nummer vergessen:

Im Lauf der Woche 22 ... 😀

Gruß BillMaier