Diskussion:Hardlink

Erste Anmerkung zur Einordnung

Bei diesem Artikel ist einzugrenzen, auf was er sich bezieht. Die Begrifflichkeit ist zu allgemein gehalten, Details sind irreführend (NTFS aufgeführt - es gibt aber keine Inodes dort). Und UNIX ist kein Dateisystem.--Yanestra 06:05, 1. Mär 2006 (CET)

Die Allgemeinverständlichkeit ist verbesserungswürdig

Liebe Artikelverfasser ! Mein Nachschlag in der Hoffnung zu erfahren, was ein Harter Link ist endete mit einem Erkennntnisgewinn von nahezu Null.
Ein harter Link (engl. Hard link) ist ein Eintrag in einem Dateiverzeichnis bei einem Dateisystem (z. B. ext3).
Heißen alle Einträge in Dateisystemen "Hard Link" ? Oder ist es einer von mehreren ? Wenn ja, mit welcher Spezifik ? In welchen Dateisystemen ? Ist es eine prinzipielle Sache, um die kein Dateisystem herumkommt oder eine spezielle Technik von ext3 ? Gibt es bei FAT32 auch inodes ? Wenn nein, kann man doch nicht mit etwas erklären, was es nur in bestimmten Dateisystemen gibt, es sei denn, nur hier gibt es Hard Links ??? Worauf verweist dieser Link ? Auf den physikalischen Ort auf der Platte ? Wer greift über diesen Link (auf was?) zu, wer, welche Soft- oder Hardware nutzt diese ?
Alle Details, die ich zunächst gar nicht wissen wollte, helfen mir nicht, wenn mir nicht klar wird, was für eine Art Ding ein Hard Link überhaupt ist.
--Kapuzino 04:23, 13. Okt. 2006 (CEST)

Ich schließe mich der Meinung Kapuzinos an. masao 01:08, 19. Okt. 2007 (CEST)

Hard Links auf Verzeichnisse

Apple Mac OS X 10.5 wird hard links auf Verzeichnisse mit HFS+ zulassen, das ist integraler Bestandteil der "Time Machine"-Funktion.
Die Sektion "..dürfen Benutzer keine zusätzlichen Links für Verzeichnisse anlegen..." hat sich damit als obsolet herausgestellt ohn eine weitere Erklärung der Nachteile von Hard Links auf Verzeichnisse.
Die Tatsache, dass es bisher von niemandem implementiert wurde, zählt genauswenig wie "technisch im Linux-Kernel nicht möglich" oder andere "Nicht-Gründe".
Der Abschnitt muss konsequenterweise entweder komplett überarbeitet ("Die meisten Betriebssysteme erlauben keine hard links auf Verzeichnisse, da...") oder schlicht ganz weggeworfen werden.
(Der vorstehende Beitrag stammt von Thorongil (Beiträge) – 15:31, 8. Jun. 2007 (MESZ) – und wurde nachträglich unterschrieben.)

Frage zum Verhalten bei Überschreibung

Wie verhalten sich eigentlich Harte Links beim überschreiben?
(Der vorstehende Beitrag stammt von 213.196.146.185 – 11:53, 5. Sep. 2007 (MESZ) – und wurde nachträglich unterschrieben.)

Die Datei wird überschrieben. Andere Harte Links verweisen auf die geänderte Datei. --Thorongil 14:11, 27. Nov. 2007 (CET)

Hier kommt es natürlich darauf an, ob eine Datei tatsächlich zum ändern geöffnet wird (Operation auf dem nämlichen Inode), oder z. B. eine temporäre Datei erstellt und im Erfolgsfall das Original gelöscht und durch die (zunächst) temporäre Datei ersetzt wird (zwei verschiedene Inodes). Im zweiten Fall ginge natürlich die Verbindung mit den etwaigen anderen Harten Links verloren; das kann gewünscht sein oder auch nicht. --Tobias 23:42, 8. Sep. 2008 (CEST)

Überarbeitung am 1.4.2009

Ich bekenne EDV-mäßig Laie zu sein, und mich dennoch an eine Überarbeitung gewagt zu haben, nachdem der Artikel mich unlängst ein wenig in die Irre führte und ich erwartete, die etwas verworrenen Erklärungen bereinigen zu können: Zumindest weist jetzt bereits die Einleitung darauf hin, dass das Lemma auch für Windows gilt -- Laien wie meinereiner hätten das Fachchinesisch ungern oder gar nicht bis dorthin gelesen, wo dann doch noch auf das hier etwas verpönte Windows Bezug genommen wurde.
Bezüglich meiner eigenmächtigen Ergänzungen habe ich versucht mich an http://msdn.microsoft.com/en-us/library/aa365006.aspx zu halten, ohne jedoch die Funktion CreateHardLink zu erwähnen, die mir zu hoch ist. Vielleicht findet sich hier dieses Jahr noch jemand, der den Artikeltext daraufhin checkt, ob diese Funktion erwähnt werden soll und welche Vor-/Nachteile sie gegenüber der im Artikel beschriebenen Funktion hat???
Ich bekenne weiters, dass ich mich kürzlich auch über den Artikel Inode hermachte, und ersuche für den Fall dass ich irrtümlich irgendwo Fehler eingeschleust haben sollte um AGF. [w.] 12:03, 1. Apr. 2009 (CEST)

Hinweis zu Risiken und Nebenwirkungen

Ein kleiner Hinweis auf die Risiken der Verwendung von Hardlinks könnte nicht schaden. Mein Kollege hat sich am Wochenende fast alle Daten von C: gelöscht, da er einen Hardlink auf C: irgendwo in seinem Profil hatte. Wie der dorthin gekommen ist, habe ich noch nicht herausgefunden. Roman 10:11, 15. März 2010 (CEST)

Wenn dem so wäre, dann wäre das en Bug in MS-WIN aber nicht ein Problem durch die Verwendung von Hardlinks Schily 11:09, 15. Mär. 2010 (CET)

Widersprüchliche Aussagen

Auszug aus dem Artikel:

Windows

NTFS-Partitionen (nicht FAT und FAT32) unterstützen bis zu 1023 harte Links pro Datei. Zum Erstellen harter Links eignen sich beispielsweise das Programm fsutil hardlink utility (unter Windows XP), der mklink-Befehl (unter Vista) oder Programme anderer Hersteller.

Um mit dem Microsoft-Werkzeug fsutil den harten Link „Neue Linkdatei.txt“ zu erzeugen, der auf die Datei „Quelldatei.txt“ verweist, ist das folgende Kommando einzugeben:
fsutil hardlink create "Neue Linkdatei.txt" "Quelldatei.txt"

Zulässig wäre beispielsweise:

D:\dira\Anton.txt → D:\dirb\dirx\Berta.txt

oder

D:\dirc\Carla.bak → D:\dirb\dirx\Berta.txt usw.

Anders als unter Unix kann kein harter Link gelöscht werden, solange die referenzierte Datei von einer Anwendung geöffnet, d.h. ein Filehandle darauf gesetzt ist.

Anmerkungen

• Harte Links werden beim Systembackup durch Kopien der verlinkten Dateien ersetzt.
• Harte Zusatzlinks werden für „normale“ Dateien nicht sehr oft genutzt, da für mehrfache Verweise auf eine Datei auch symbolische Links zur Verfügung stehen.
• Eine verbreitete Anwendung von Hard Links ist die Erstellung von Snapshots, bei denen statt eines kompletten neuen Backups lediglich Hard Links auf ein bestehendes Backup erzeugt werden und so mit geringem zusätzlichen Speicherplatz die Veränderungen an einem Verzeichnisbaum rekonstruiert werden können.
• Unter NTFS erfüllen Abzweigungspunkte („Junctions“) eine ähnliche Funktion wie harte Links, wenn Verzeichnisse auf verschiedenen Partitionen oder Festplatten desselben Computers verlinkt werden sollen, in der Art

C:\dira → D:\dirb\dirx

Nicht möglich sind jedoch

1. die Verlinkung von Dateinamen über einen Abzweigungspunkt, wie etwa

D:\dira\Anton.txt → D:\dirb\dirx\Berta.txt

Dasselbe Beispiel wird einmal als "zulässig", einmal als "nicht möglich" bezeichnet. Was ist denn nun richtig? Abgesehen davon ist die Schreibweise mit dem Pfeil eher nichtssagend, wie ist die zu verstehen? — Daniel FR (Séparée) 11:54, 30. Jul. 2010 (CEST)

Überarbeitung der Einleitung am 23.11.2010

Ich hoffe meine Überarbeitung der Einleitung macht diese jetzt etwas Oma tauglicher. --62.224.189.7 22:52, 23. Nov. 2010 (CET)

Dein Text hat sich leider selbst widersprochen. Das besondere eines Hardlinks ist, daß er nicht mehr vom ursprünglichen Eintrag zu unterscheiden ist. Daher kann eine Datei durch einen Hardlink nicht an "anderer Stelle erscheinen". --Schily 11:19, 24. Nov. 2010 (CET)

Na doch: für den Anwender bzw. das Programm sieht es so aus, dass die Datei woanders liegt als es wirklich der Fall ist. Das ist ja der Witz am Hardlink. Nur dass der Anwender bzw. die Anwendung das erstmal nicht mitbekommt. Ich denke das gab meine Erlärung auch so her. => bitte wieder herstellen bzw. leicht abändern bis es dir passt. So wie's jetzt ist, ist es meiner Ansicht nach nämlich nicht Oma tauglich (v.a. in der Einleitung)--62.159.30.170 12:59, 24. Nov. 2010 (CET)

Das besondere an einem Hardlink ist nun mal daß man nach dem Anlegen nicht mehr sagen kann welcher Name der "Richtige" ist. Dies ist übrigens ein Artikel zum Thema Hardlink und da gehören Versuche der Hardlinkemulation aus dem DOS/WNT Bereich nur am Rande dazu. Ein Hardlink setzt ein Dateisystem voraus, daß die Dateinamen unabhängig von den sonstigen Metadaten speichert. --Schily 15:43, 24. Nov. 2010 (CET)

Einleitung unverständlich und falsch

Ein harter Link (engl. hard link, im deutschen Jargon auch Hardlink) ist ein Verzeichniseintrag in einem Dateisystem, der auf Dateien und Verzeichnisse verweist. Mit der Erstellung eines harten Links wird ein weiterer Name zu der Datei etabliert, der im Folgenden nicht mehr von den früheren Namen der Datei zu unterscheiden ist. Komplett unverständlich - und grundfalsch:

• Ein Verzeichniseintrag verweist entweder auf eine Datei (Singular) oder ein Verzeichnis.
• „ein weiterer Name ..., der nicht von den früheren Namen der Datei zu unterscheiden ist.“ Ein Name der von einem Namen nicht zu unterscheiden ist - bisher ist mir ein Dateisystem, dass Einträge mit nicht unterscheidbaren Namen zulässt, noch nicht über den Weg gelaufen.
  

Gemeint ist wohl: ... ist ein Verzeichniseintrag in einem Dateisystem, der einen Namen mit einer Datei assoziiert. Mit dem Erstellen eines harten Links wird ein weiterer Verzeichniseintrag auf eine bereits bestehende Datei erzeugt.
Noch ein Hinweis, viele Dateisysteme lassen einen Hardlink auf ein Verzeichnis gar nicht zu: "hard link not allowed for directory" sagt mein ext4fs. Gruß, --Burkhard 22:24, 11. Feb. 2011 (CET)

Fragen zur Sicherung (Backup)

Im Artikel steht:

"Harte Links werden beim Systembackup durch Kopien der verlinkten Dateien ersetzt."

Meine Fragen dazu:

• Auf welchem Betriebssystem?
• Welches der vorhandenen "Systembackup-Mechanismen bzw. -Programme" ist gemeint?
• Wieso sollte das passieren, das Backup würde doch sehr sehr groß werden?

(nicht signierter Beitrag von 213.23.14.170 (Diskussion) 12:21, 8. Jul 2011 (CEST))

Ich verstehe die Anmerkung auch nicht so ganz. Wenn man ein Backup auf einem anderen Medium macht, kommt man um das Kopieren ja nicht herum. Bei einem Backup auf der selben Partition, wäre ein harter Link auf die zu sichernde Datei ziemlich sinnfrei. (Soll auf diese Tatsache hingewiesen werden?)--Cebus 10:21, 9. Jul. 2011 (CEST)

Gemeint ist evtl, dass auf dem Backupmedium aus aus Hardlinks unabhängige Kopien werden - als allgemein formulierte Aussage ist das natürlich Blödsinn. Wie mit Links beim Backup umgegangen wird hängt u.a. von den Fähigkeiten der eingesetzten Backupsoftware ab. --Burkhard 12:53, 9. Jul. 2011 (CEST)

Ein Backup-Programm das Hardlinks nutzt ist zum Beispiel HardlinkBackup http://www.lupinho.net/hardlinkbackup/ Was für mich noch nicht klar ist, was passiert wenn die Ursprungsdatei beschädigt ist oder aus versehen gelöscht wird? --TomW 17:32, 23. Dez. 2011 (CEST)

Es gibt das ursprüngliche Arbeitsverzeichnis und verschiedene Kopien dieses Verzeichnisses, die als Backup dienen. Harte Links werden nur verwendet, um den Speicherplatz für die verschiedenen Backupverzeichnisse zu reduzieren, das Arbeitsverzeichnis bleibt dabei unangetastet. Nach dem ersten Backup ist also jede Datei genau zwei mal auf der Festplatte, beim zweiten Backup werden nur die veränderten Dateien kopiert. Für unveränderte Dateien wird ein harter Link auf die entsprechende Datei im ersten Backup gesetzt. --Cebus 11:24, 28. Dez. 2011 (CET)

Überarbeitung der Einleitung am 19.5.2013‎

Ich habe einige Kritikpunkte hier aufgenommen und die Einleitung dementsprechend überarbeitet. Im Wesentlichen habe ich einen Absatz vorangestellt, der möglichst knapp einem Laien die harten Links näherbringen soll. Die beiden alten ersten Absätze habe ich dahingehend angepasst. Dabei habe ich um der Strukturierung Willen ein paar Redundanzen inkaufgenommen. Die Warnung bzgl. des Wortes Dateideskriptor habe ich angenommen und somit versucht, den Begriff ganz zu vermeiden, auch wenn es dafür jetzt mehrfach "Inode oder File Record" heißt. Den Satz mit "Ursprungsdatei" habe ich ganz weggelassen, weil aus ihm der Geist der symbolischen Links atmet. -- Pemu (Diskussion) 15:46, 19. Mai 2013 (CEST)

Bitte die Belegpflicht und den sogenannten neutralen Standpunkt beachten

Also einen Beleg (oder eine auch sogenannte ‚ref‘) – wie etwa diesen (Einzel-)Beleg – zu entfernen, nur weil Dieser nicht gefällt (oder angeblich [wegen] M$ unwichtig [oder ‚irrelevant‘] ist, wörtliche Begründung „irrelevante M$ ref entfernt“^[1]), obwohl es demgegenüber (also dieser persönlichen Ansicht, die ich in diesem Fall hier nicht teile) hier in der Wikipedia aber sogar eine Belegpflicht gibt, finde ich nicht in Ordnung. Wenn es einen besseren Beleg gibt, hätte der ach so böse M$-Beleg – dazu möchte ich nocheinmal ausdrücklich betonen, daß das hier nicht meine [persönliche Ab-]Wertung ist, siehe ggf. auch nochmal Wikipedia:Neutraler Standpunkt – ja gerne ausgetauscht oder ersetzt aber bitte nicht einfach ersatzlos entfernt werden können. -- 9ai877, am 1.5.2016, 08:54 (MESZ)

Bitte ergänzen: Wie entfernt man einen harten Link?

Die Überschrift heisst "Harter Link", nicht "Harter Link anlegen". Daher sollte auch die Entfernung desselben beschrieben werden.

Einfach entfernen/löschen, so wie jede Datei. Das Löschen wird auch im Abschnitt "Einführung" thematisiert. RealSebix (Diskussion) 10:58, 26. Sep. 2020 (CEST)

Ich denke auch, der Artikel heißt genausowenig "Harter Link löschen".

Vielleicht passt an geeigneter Stelle ein Link auf rm (Unix) – wobei der Artikel naturgemäß BS-spezifisch ist.

-- Pemu (Diskussion) 00:17, 7. Okt. 2020 (CEST)

Besser wäre (allgemein und heimat-, hier also deutschsprachig) auf Löschen (Informatik) (oder ggf. genauer, auf das üblicherweise wohl zum Einsatz kommende logische Löschen) zu verweisen (wobei, allein schon aus Geschwindigkeitsgründen, eben üblicherweise wohl so ein „harter“ Verweis, bspw. mit Reflink -1, lediglich schnell)gelöscht wird (und der OS-spezifische Kram oder BS-bezoge Teil sollte ggf. besser nur noch im Haupteintrag zum Löschen genannt werden). Mit lieben Grüßen. -- 77.183.221.217 10:22, 9. Dez. 2023 (CET)

Verstehe ich nicht. -- Pemu (Diskussion) 22:46, 12. Dez. 2023 (CET)

Zusammenhang mit Symbolischer Verknüpfung und Dateiverknüpfung

Einladung zur Diskussion auf Symbolische Verknüpfung #Verwaltung von symbolischen Verknüpfungen im grafischen Dateiverwaltungsprogramm.

‣Andreas•⚖ 09:21, 5. Dez. 2023 (CET)

Lemma: im deutschen Fachjargon auch Hardlink...

Eigentlich ist im Deutschen nur der "Fachjargon" vorzufinden. Wer eine Internet-Suchmaschine (googeln...) beübt, wird feststellen, dass es meistens "Hardlinks" sind, auch im Deutschen, und nur ganz selten "Harte Links"... Meist wird es in deutschen Formulierungen zerbrochen, etwa wird aus dem Englischen "hard and softlinks" oder "hard and symbolic links" dann "harte und weiche/symbolische Verknüpfungen" oder "harte und weiche Links", wie etwa hier. Aber wenn das Wort alleine vorkommt, dann doch durchwegs als "Hardlink".

Ich schlage daher vor, den Artikel zu Hardlink zu verschieben und die Einleitung dementsprechend anzupassen.

Beispiele:

• Hardlinks und Junctions
• Dateiverknüpfungen als Hardlinks anlegen
• Link Shell Extension: GUI-Tool für Hardlinks und symbolische Links
• Umgang mit Hardlinks

u.v.m.

Meinungen dazu? Widersprüche? Wenn nicht, mache ich es demnächst (bald)...

‣Andreas•⚖ 16:09, 6. Dez. 2023 (CET)

Also ich fand’s anfangs komisch, so gewollt ins Deutsche übersetzt; mittlerweile habe ich mich daran gewöhnt.

Aber ich finde die Übersetzung eh komisch. Denn wenn ich darüber nachdenke, finde ich für die Eigenschaften "hart" und "weich" keine Begründung. Also ich meine, ich sehe nicht, warum man die Konzepte als "hart" und "weich" bezeichnet hat. Meine TF: Man hat die unterschiedliche Tiefe der Implementierung in einem aus horizontalen Schichten gedachten System als Namensgeber benutzt. Der Mechanismus, der näher in Richtung Schicht Hardware (im Dateisystem(treiber)) implementiert ist, heißt/macht nun "Hard Link(s)"; der weiter weg von der Schicht Hardware (näher in Richtung Schicht Benutzer) heißt "Soft Link". Insofern empfinde ich diese Bezeichnungen als Namen und würde es gar nicht übersetzen, genauso, wie ich den deutschen Artikel zu einer Band mit dem Namen The Sisters of Mercy weder Die Sisters of Mercy noch Die barmherzigen Schwestern nennen wollen würde. -- Pemu (Diskussion) 01:39, 8. Dez. 2023 (CET) und -- Pemu (Diskussion) 22:46, 12. Dez. 2023 (CET)

Das Konzept heißt im Englischen erstmal "link", was z.B. mit "Namensreferenz" übersetzt werden kann. "hard/softlinks" werden auch als "Verknüpfung", "Namensverweise", aber auch als "Querverbindung" übersetzt, je nach Fachbuch, das man sich anschaut. Diese hardlinks waren erstmal nichts anderes, als die Möglichkeit des Dateisystems, mehr als nur einen Dateinamen mit derselben Datei zu verbinden -- denn im Unix-Dateisystem wird ja bekanntlich zwischen der Datei und deren Dateinamen unterschieden. Ein Hardlink ist nichts anderes, als derselben Datei einfach mehrere Namen zu geben.

Bei anderen Dateisystemen ist das nicht möglich, weil sie anders aufgebaut sind. FAT z.B. kann keine Hardlinks bereitstellen, weil Datei und Dateiname per Design in der Tabelle zusammen gehören. Ein zweiter Dateiname hat also eine zweite Datei zur Folge, und damit hat man bei hardlinks bereits ein Problem: wenn man eine der beiden Dateien verändert, dann wird die zweite korrumpiert... oder, man betreibt den Aufwand, bei jeder Änderung das gesamte Dateisystem nach einer zweiten Datei zu durchsuchen, die auf derselben Adresse liegt -- daher ein Hardlink ist -- und zieht diese dann nach...

Aber so weit wollte ich ja eigentlich gar nicht ausholen.

1985 kamen "symbolic links" dazu, die auch "soft links" genannt wurden, weil sie im Dateisystem ganz anders abgebildet werden: wie Dateiverknüpfungen unter Windows, .lnk-Dateien, enthalten Symlink nämlich Daten, genauer gesagt einen Dateinamen und deren Pfad. Dieser kann absolut oder relativ sein, das macht keinen Unterschied, denn der Kernel erhält beim Zugriff auf einen "soft link" die Information, dass die Datei gar nicht da ist, sondern wo anders: "schau bitte dort nach!", was der Kernel dann auch tut.

"Symlinks" sind damit beides: eine Struktur des Dateisystem und eine Funktion des Kernel, gemeinsam.

Die Unterschiede:

• Ein Hardlink kann immer nur auf einem und demselben Dateisystem existieren. Theoretisch könnte man auch Hardlinks auf Verzeichnisse erstellen (Verzeichnisse sind im Dateisystem nichts anderes als wieder Dateien, die aber eben den Inhalt des Verzeichnisse -- die enthaltenen Dateinamen -- verwalten), aber das wird vom System unterbunden, weil das Probleme beim rekursiven Arbeiten bedeuten würde, wie beispielsweise Endlosschleifen.
• Ein Symlink kann auf alles Referenzieren, was einem gültigen Dateipfad (Verzeichnispfad + Dateiname) entspricht, ob relativ oder absolut, und ob dieser nun existiert oder nicht, ist egal. Damit kann ein Symlink auch eine Datei oder ein Verzeichnis auf einem ganz anderen physischen Dateisystem referenzieren, oder sogar auf einem Netzlaufwerk. Und natürlich auch auf Verzeichnisse, weil Symlinks anders behandelt werden als Hardlinks, und Unix-Werkzeuge beim rekursiven Verarbeiten eine Schleife aufbrechen können, bzw. sich bewusst dazu entscheiden, symbolischen Verzeichnisverknüpfungen nicht zu folgen.

Aber ich hole zu weit aus.

TL;DR Im Deutschen findet sich eher "Hardlink" als "harter Link".

Ich bin gerade dabei, mich einzulesen und werde bei Gelegenheit die Artikel Verknüpfung (Computer), Dateiverknüpfung, Symbolische Verknüpfung und diesen Artikel, der hoffentlich bald Hardlink heißt, zu überarbeiten.

Mfg, ‣Andreas•⚖ 12:44, 8. Dez. 2023 (CET)

Hier ging es doch nur darum, ob man den ganzen Artikel nach "Hardlink" verschieben sollte. Btw. ich wäre dafür, mit dem Daumen müde halb nach oben gehalten.

Ansonsten meine Anmerkungen zum Vorgesagten:

• Weiß nicht, wie es bei Unix ist, aber es gibt nicht das eine Linux-Dateisystem.
• "Bei anderen Dateisystemen ist das nicht möglich": Das klingt so, als ob es nur ein Dateisystem gäbe mit Hardlinks, alle anderen könnten das nicht. Vermutlich können die meisten Dateisysteme, die in den letzten Jahrzehnten entwickelt wurden, Hardlinks (inkl. NTFS).
• Ich verstehe nicht, wie das bei Hardlinks und FAT und den beiden Dateien dazu kommen soll, dass die zweite Datei korrumpiert wird. Und wie man das verhindern kann, indem man das Dateisystem (also ein FAT-Dateisystem?) nach einer Datei auf derselben Adresse (?) absucht. Ich verstehe überhaupt nicht, wie das gehen soll, außer dass beim Kopieren eines Dateibaums (mit zwei Links zu einer Datei) von einem hardlinktauglichen Dateisystem auf ein FAT-Datenträger eben zwei Dateien dort entstehen. Aber von denen würde nicht die eine korrumpiert werden, sondern ja lediglich unverändert bleiben. Und zum Absuchen fällt mir jetzt nur ein, identische Dateien auf dem Datenträger zu suchen. Aber dann wüsste man noch nicht, ob sie auf dem ursprünglichen (hardlinktauglichen) Quelldatenträger nicht auch zwei Dateien (und nicht eine mit zwei Links) waren. (Ich gehe mal davon aus, dass der Versuch, einen Hardlink zu einer vorhandenen Datei direkt auf einem FAT-System zu erstellen, mit einer Fehlermeldung quittiert wird.)
• "1985": So, wie ich das verstanden habe, ist es eben nicht so. Bei Softlinks schaut der Kernel woanders nach, bei .lnk-Verknüpfungen muss das die Anwendung machen (bzw. sich darauf verlassen, dass es die startende Umgebung gemacht hat).

-- Pemu (Diskussion) 22:46, 12. Dez. 2023 (CET)

Zu: „Denn wenn ich darüber nachdenke, finde ich für die Eigenschaften "hart" und "weich" keine Begründung.“:

Dahinter steht wohl (ursprünglich, rein gedanklich), daß die „harten“ Verweise einfach mal näher an der Hardwa(h)re (sind oder) waren und (demgegenüber) die „Weichen“ (Softlinks, wenigstens ursprünglich wohl) leichter änderbar waren. Mit lieben Grüßen. -- 77.183.221.217 10:26, 9. Dez. 2023 (CET)

Klingt für mich so, also ob 77.183.221.217 auch keine besseren Belege hat als ich. -- Pemu (Diskussion) 22:46, 12. Dez. 2023 (CET)

Auch „Harter Verweis“ genannt

(Anschließend zum vorhergehenden Abschnitt, zugehöriger Dauerverweis:) Und weiter (aus dem Amerikanischen) übersetzt auch schonmal (in freier Wildbahn) „Harter Verweis“ genannt (oder wenigstens so bezeichnet), siehe auch unter JavaScript-Paketmanager pnpm vermeidet doppelte Packages (bei Heise, am 28.5.2020, um 09:41), dort, nach der (gebeugten oder auch flexierten/flektierten Mehrzahl-)Abschnittsüberschrift „Harte Verweise“ dann, im ersten Absatz abschließend, mit: „Für Dateien mit identischem Inhalt speichert der Paketmanager lediglich Hardlinks.“ Und der gegenwärtig auch (noch?) umseitig verwendete Bezeichner mit der (langen/sperrigen) „Verknüpfung“ ist wahrscheinlich auch nur eine Lehnübersetzung, welche mutmaßlich von Mikrosoft (Deutschland) stammt – dort (genauer bei ihrem Windows) werden wohl alle (Dateisystem- oder auch als Datei abgelegte) Verweise (siehe auch .lnk), schon eine ganze Weile (nach der Lokalisierung, also spätestens wohl seit ihrem Windows 95) eben als „Verknüpfung“ bezeichnet. Mit lieben Grüßen. -- 78.54.45.228 08:19, 12. Dez. 2023 (CET)

In dem Heise-Artikel sehe ich die Zwischenüberschrift nicht als etablierte Verwendung von "Harter Verweis" für den hier zur Diskussion stehenden Begriff. In die Zwischenüberschriften fließen schon mal sprachliche Spielereien ein; eine Etablierung von Nomenklatur würde ich daraus keinesfalls ableiten. -- Pemu (Diskussion) 22:46, 12. Dez. 2023 (CET)

Nur Unix?

Mir geht es um die mit dieser Änderung einhergehende Einengung auf Unix. Warum? Das gesagte gilt doch auch z.B. für Windows mit NTFS. Oder zahlreiche Gnu-Linuces. Vermutlich auch für Mac. -- Pemu (Diskussion) 23:12, 12. Dez. 2023 (CET)

Nein, es geht nicht nur um Unix. Aber alle alten Bücher, die ich bis jetzt über Hardlinks gefunden habe, schreiben "Unix". Mein Versuch war es, herauszufinden, wo Hardlinks herkommen bzw. wo Hardlinks das erste Mal eingesetzt wurden. Die frühesten Bücher dazu, die ich fand, kommen aus den 1980ern. Zur Erinnerung: Damals gab es MS-DOS. OS/2 und HPFS wurde erst entwickelt. NTFS gab es noch nicht. Die bekannten Dateisysteme waren das von Unix, ob es nun UFS war oder nicht, ist mir leider nicht bekannt, aber es wird wohl UFS1 oder ein Vorläufer davon gewesen sein.

Interessanter Weise kann ich nichts dazu bei Multics oder anderen Systemen, etwa OS/360 oder den Vorläufern davon, finden. Frühe Betriebssysteme waren Time-Sharing-Systeme auf Mainframes und natürlich CP/M. CP/M und MS-DOS unterstützten keine Hardlinks.

Aber, natürlich kann man das auch anders formulieren, und natürlich muss das noch verbessert werden. Hilfe ist willkommen. Von meiner Seite ist das ganze Work-in-Progress, aber es wird noch etwas dauern. ‣Andreas•⚖ 00:03, 13. Dez. 2023 (CET)

Das klingt für mich danach, sich an der Quellenlage (und der Geschichte) entlangzuhangeln.

Die ganze Einleitung ist ja nicht mit Einzelbelegen belegt. Ich würde in der Einleitung nicht Wert auf enge Quellenauslegung oder geschichtliche Akkuratesse legen, daher möchte ich für diese Stelle für eine Formulierung in der Richtung wie die alte ("moderne Systeme") werben.

Weiter unten (irgendwo hinter dem Inhaltsverzeichnis) würde ich (vielleicht sogar mit Jahreszahlen) die Entwicklung darstellen.

-- Pemu (Diskussion) 01:55, 14. Dez. 2023 (CET)

Moderne Systeme? Ich würde das ganze lieber umdrehen. Heute ist es quasi Standard, es gibt so gut wie kein System, das keine Hardlinks unterstützt. Ich würde also von historischen Systemen sprechen, die das noch nicht unterstützt haben.

Aber ich verstehe dich, und ich habe auch nichts dagegen, wenn du das alles umformulierst. Ich bin im Moment gerade mit etwas anderem beschäftigt, komme aber sobald als möglich auf die Hardlinks zurück. Eigentlich sogar auf alle Links (Dateiverknüpfungen), auch symbolische Verknüpfungen und Verknüpfung (Computer). ‣Andreas•⚖ 02:03, 14. Dez. 2023 (CET)

Darum geht es doch: Moderne Systeme unterstützen Hardlinks.

Ich habe mal die Einleitung in meinem Sinne etwas abgeändert. An dieser Stelle (Einleitung) habe ich mich entschlossen, nicht auf die verschiedenen Bezeichnungen für die Nummern einzugehen. Stattdessen möchte ich vorschlagen, folgenden Text aufzunehmen (solange es nicht umfangreicher wird, ist mein Vorschlag, einfach in einem Absatz zwischen der Überschrift "Einführung" und dem folgenden "Beim Erstellen der Datei erzeugt …"):

Bei Unix-Dateisystemen entstand die Idee der Hardlinks mit der der Inodes (Knotennummern) in den 1970er-Jahren. In Folge benutzen seit den 1980er-Jahren alle unixoiden Systeme Dateisysteme, die Hardlinks unterstützen. Im Bereich der Microsoft-Systeme erfolgte mit NTFS (mit File-Record-Nummern) der Übergang zu einem hardlink-tauglichen Dateisystem. Apple führte schon vor dem Übergang zum unixoiden OS X das hardlink-taugliche HFS+ ein.

Da noch nicht ausgegoren und ich keine richtigen Quellen dazu habe, schreibe ich das erstmal hier (auf der Disk.).

-- Pemu (Diskussion) 10:50, 14. Dez. 2023 (CET)

Danke, das war genau mein Problem: ich finde keine Quelle. Sind wir also schon zu zweit... ‣Andreas•⚖ 11:19, 14. Dez. 2023 (CET)

"Moderne Dateisysteme"

Noch kurz zur Motivation des vielleicht ein bisschen schwammig klingenden "Moderne Dateisysteme": Für den Zweck hier (Einleitung) wird dadurch vermieden, genaue Fallunterscheidungen (Windows nur mit NTFS, Mac ab <HFS+, keine Ahnung>) zu brauchen, um nichts Ungenaues zu schreiben. Wenn man heutzutage ein System mit Defaults aufsetzt, hat man vermutlich zu 99,X % eines, das Hardlinks kann. (Und vermutlich hat man, wenn man ein -ix aufsetzt mit einem Filesystem, das keine Hardlinks kann, zu 99,X % eines, das nicht funktioniert ;). -- Pemu (Diskussion) 10:50, 14. Dez. 2023 (CET)

Es passt für mich. Ich danke dir, dass du dir den Kopf darüber zerbrochen hast und es dir nicht leicht gemacht hast, einfach irgendwas zu schreiben, sondern es auch zu begründen. Nochmals danke. ‣Andreas•⚖ 11:20, 14. Dez. 2023 (CET)

Zeiger

Auf die Zeiger könnte zudem wenigstens (erstmal nur im Siehe-auch-Abschnitt) auch noch (ver- oder) hingewiesen werden, da diese wohl (vom Grundgedanken her) der Ursprung (auch der harten Verknüpfungen/… Verweise/Hartverweise/Hardlinks) sind. Diese wurde wohl „1964/65 [über PL/I und IBM, vom US-Amerikaner Harold Lawson erfunden]“.^[Beleg] Mit lieben Grüßen. -- 77.191.208.122 15:35, 14. Dez. 2023 (CET)

Sehe ich nicht so. Eher stehen sowohl Zeiger als auch (Hard)links für eine Implementierung einer Referenz. Mit dem gleichen Argument könnte man dann unter "Siehe auch" z.B. auch Hyperlink, Querverweis etc. aufführen.

Und dass Zeiger erst 1964 erfunden worden sein sollen, glaube ich nicht. Ich vermute, dass dann eher zum ersten Mal eine Formalisierung des Konzepts stattfand. Z.B. heißt es in Adressierung (Rechnerarchitektur): "Die indirekte Adressierung wurde 1953 von Heinz Schecher patentiert".

-- Pemu (Diskussion) 23:58, 14. Dez. 2023 (CET)

Die Referenz, also (in meiner Sprache übersetzt) ein „Verweis auf etwas oder jemanden, […]“ ist hier aber (jedenfalls aus meiner bescheidenen Sicht) ganz offensichtlich mit dem Zeiger („[…] in diesem Sinne auch als Referenz[blabla] bezeichnet.“) gleichbedeutend (oder auch, hier gegenwärtig noch immer, verrückterweise bevorzugt fremdverschwurbelt, synonym; oder siehe dazu ggf. auch unter Dateiverknüpfung, dort gegenwärtig auch mit zugehörigem Verknüpf­ungs­symbol, welches, jedenfalls aus meiner Sicht, doch auch sehr nach einem Zeiger [→] aussieht).

Zum geschichtlichen Teil: So steht es nunmal (gegenwärtig, wörtlich mit „erfand“) im oben genannten Eintrag, zu Harold Lawson. Dann, das Heinz Schecher die von ihm(? oder damals/später von anderen?) wohl sobezeichnete indirekte Adressierung „erfand“ und, naja, (selbst?) patentierte (oder wohl eher patentieren ließ), könnte ja mal in diesem Zusammenhang auch offener, wenigstens zum betreffenden Zeiger (wo dieser [geschichtliche] Teil gegenwärtig/bisher noch NICHT genannt ist oder verschwiegen wurde) ergänzt werden.

Und was die anderen (von dir hier nun eingebrachten) Verweise (genauer die zum [allgemeineren] Verweis gehörigen Unterbegriffe, Hyperlink und Querverweis) angeht: Nein, diese sollten hier, zum (solange es keinen besseren Bezeichner dazu gibt, wenigstens von mir hier kurz sobezeichneten) Hartverweis (oder auch Hartzeiger/harter Zeiger, auf Dateisystem-Ebene), wohl besser NICHT untergemischt (ggf. ganz klar abgeschieden/ausgesondert oder, wenn dann aber mit dem Querverweis, nur noch als eine Art Beispiel genannt) werden. Mit lieben Grüßen. -- 78.55.209.135 11:45, 15. Dez. 2023 (CET)

In keinem einzigen Buch, in dem ich über den "hardlink" bis jetzt gelesen habe, wie der funktioniert und was der ist, stand "Zeiger". Ich bin zwar immer aufgeschlossen gegenüber Verbesserungen, aber dann sollte das zumindest irgendwo "da draußen" (denn das soll die Wikipedia ja abbilden) zu finden sein. ‣Andreas•⚖ 13:15, 15. Dez. 2023 (CET)

Entschuldigung, ich bin raus. Tc;du (Too complicated; didn't understand). -- Pemu (Diskussion) 21:30, 15. Dez. 2023 (CET)

Ich auch, außer es gibt noch eine Quelle, die das allgemeinverständlich erklärt. Ein Fachbuch z.B. ‣Andreas•⚖ 21:40, 15. Dez. 2023 (CET)

In en:Modern Operating Systems von Andrew S. Tanenbaum steht (S. 783, 5. Auflage 2022, https://csc-knu.github.io/sys-prog/books/Andrew%20S.%20Tanenbaum%20-%20Modern%20Operating%20Systems.pdf): "As we saw in Fig. 10-24, linking to a file creates a new directory entry that points to an existing file." Also, der Verzeichniseintrag zeigt auf eine existierende Datei.

Offenbar sieht AST keine Notwendigkeit, einen neuen Fachbegriff (Zeiger/Pointer) für etwas einzuführen, was sich durch ein einfaches Verb (to point at/auf etw. zeigen) beschreiben lässt. Ich vermute, dass die meisten Fachautoren das genauso halten. Gruß, --Burkhard (Diskussion) 23:12, 15. Dez. 2023 (CET)