Warum ist /tmp ein Symlink zu /private/tmp?

Warum ist /tmpein Symlink /private/tmpauf Mac OS X? Mit anderen Worten, warum ist es nicht /tmpnur ein normales Verzeichnis, wie unter Linux oder BSD? Ich verstehe, wie es funktioniert, und es macht mir nichts aus, ich interessiere mich nur für die (historische?) Begründung dahinter.

Antworten (5)

So wie ich es verstehe, ist es ein Überbleibsel von NextStep (auf dem OS X basiert), und NextStep hat es getan, um NetBooting zu unterstützen. Die Idee war, dass Sie von einem im Netzwerk gehosteten Volume booten könnten (wahrscheinlich schreibgeschützt und sicherlich mit anderen Computern geteilt) und früh im Bootprozess ein lokales (beschreibbares) Volume auf /private mounten könnten; wie g erwähnte, ermöglichte dies Laufzeitänderungen von /var und /tmp sowie computerspezifische Einstellungen in /etc.

Dies ist nicht mehr erforderlich, da das aktuelle NetBoot-System von Apple ein Schatten-Disk-Image verwendet, um Änderungen überall auf dem Startvolume zu speichern. Aber einige Programme/Dokumente/etc gehen jetzt davon aus, dass die Dateien unter /private leben, also wäre es zu viel Mühe, sie zurück zu schalten ...

Update: Seit ich dies geschrieben habe, hat Apple die Unterstützung von NetBoot eingestellt, sodass der ursprüngliche Zweck von /private noch veralteter ist. In macOS Catalina (Version 10.15) haben sie jedoch eine neue Volume-Aufteilung hinzugefügt. In diesem Fall dient es eher der Sicherheit als der Unterstützung von NetBoot, aber es funktioniert auf ziemlich ähnliche Weise.

Das Systemvolume von Catalina ist schreibgeschützt gemountet, mit einem Read-Write-Volume, das unter /System/Library/Data gemountet ist (analog zum alten System, das ein RW-Volume unter /private gemountet hat), und „Firmlinks“, die Teile des RW-Volumes erscheinen lassen an ihren üblichen Stellen im Dateisystem (wieder analog zu den symbolischen Links, die Teile von /private an ihren üblichen Stellen erscheinen lassen). Beispielsweise ist /Users jetzt ein fester Link zu /System/Library/Data/Users. Die Eclectic Light Company hat eine gute Zusammenfassung .

Catalina hat auch noch die symbolischen Links zu /private; Wenn Sie also auf Catalina auf /etc zugreifen, folgt es dem Symlink zu /private/etc und dann dem Firmlink zu /System/Library/Data/private/etc

"Aber einige Programme/Dokumente/etc" lolpun (etc ist symbolisch mit /private/etc verknüpft)

Ich habe mich immer dasselbe gefragt. Ich kann keine Dokumentation finden, die dies unterstützt, aber normalerweise wird dieses Muster verwendet, um das Speichern von Dateien auf einem anderen Volume (z. B. Festplatte) zu vereinfachen. Dadurch kann das Laufwerk an einer Stelle in das Dateisystem eingebunden (z. B. angehängt) werden. Zum Beispiel, wenn das Laufwerk unter gemountet ist /privateund sich dann die Ordner /etc, /tmp, und /varalle auf diesem anderen Laufwerk befinden.

Was ich nicht sagen kann, ist, warum dies von Vorteil wäre. Beachten Sie jedoch, dass diese drei Ordner „Daten“-Dateien wie Konfigurations-, Temporär-, Protokoll-, Übergangs- und Datenbankdateien enthalten und keinen ausführbaren Code, der in den Ordnern /bin, /sbinund enthalten ist./usr

Ich bin mir über den historischen Grund nicht sicher, aber OS X hat die typische Unix-Struktur immer „reorganisiert“. /tmpist nicht das einzige, was zu geht /private, es hat auch /etcund /var.

Vielleicht kann sich jemand mit mehr OS X-Hintergrund etwas Vernünftigeres einfallen lassen.

/tmpist ein symbolischer Link, /private/etcum zwei klar getrennte Dateisysteme zu verwalten:

  • /die schreibgeschützt gemountet werden kann, um sie vor zufälligen oder unerwünschten Änderungen zu schützen und um zu verhindern, dass sie mit immer mehr Dateien (Protokolle und temporäre Dateien) gefüllt werden,

  • /privatedie mit Lese- und Schreibzugriff gemountet werden können und die ein beliebiges Verzeichnis enthalten, das modifizierbare Dateien enthält.

Wenn Sie sich das ansehen /, werden Sie 3 Verzeichnisse bemerken, die aus demselben Grund ähnliche symbolische Links sind:

cd /
ls -al | grep '> private'

Diese Trennung des Zugriffs zwischen Read-Write- und Read-Only-Dateisystemen wird eigentlich nicht verwendet (in MacOS X), aber es ist alles vorhanden, um diese Sicherheitstrennung zu erreichen.

Einige Administratoren erzwingen diese Sicherheitstrennung, indem sie ein bestimmtes /privateDateisystem mit der entsprechenden Größe und den entsprechenden Mount-Optionen definieren (insbesondere nosuid).

Dies ist die beste Antwort.

Identische Wege derselben Sache sind in Unix häufig auf historische Unterschiede zwischen System V Unix und BSD Unix zurückzuführen. Moderne Unixe müssen beide unterstützen, um kompatibel zu sein.

Zum Beispiel lprund lpzum Drucken: lprstammt von BSD und lpstammt von System V.

Ob das hier der Fall ist, weiß ich nicht.