Warum ist das Linux-Dateisystem als ein einziger Verzeichnisbaum konzipiert?


91

Kann jemand erklären, warum Linux als einzelner Verzeichnisbaum konzipiert ist?

Während in Windows mehrere Laufwerke vorhanden sein C:\können D:\, gibt es in Unix nur ein einziges Stammverzeichnis. Gibt es einen bestimmten Grund?


14
@terdon - Ich glaube, er fragt nach einem einzigen Root-Verzeichnis (/) im Vergleich zu DOS-Stil (C: \ D: \).
Jordan

27
Sie können (und tun es normalerweise) auch unter Linux mehrere Laufwerke. Tatsächlich ist das Grundprinzip dasselbe C:und D:es handelt sich auch in Windows um Einhängepunkte. Das Windows-Äquivalent von /ist My Computer, alles ist darunter gemountet.
Terdon

61
Ich denke, eine relevantere Frage wäre: "Warum sollte ein Betriebssystem KEINE einzige Wurzel haben?" (Die Antwort für DOS / Windows wäre Designfehler / Planungsfehler für die Zukunft / unnötige Annahme)
JoelFan

21
Windows entschied sich aufgrund von MS-DOS für dieses bizarre System, und MS-DOS folgte dem von CP / M festgelegten Präzedenzfall. MS-DOS war ein auf Diskettenlaufwerken basierendes System (A: und B: anfangs manchmal z. B. auf einem einzelnen Laufwerk, A: und B: dasselbe Laufwerk, aber zwei verschiedene logische Datenträger für den Austausch- / Kopiervorgang). . Wie die meisten Menschen, die durch MS-DOS-PCs beschädigt wurden, ist das OP der Meinung, dass es /unter Linux dasselbe ist wie C: unter MSDOS / Windows, wenn es nicht wirklich dasselbe ist.
Warren P

25
Eigentlich C:, D:und so ist nur die Kompatibilität mit DOS und Win32; Windows NT hat intern eine etwas UNIX-ähnliche Objekthierarchie, wobei die Laufwerksbuchstaben (und generell Win32-Sachen) nur symbolische Verknüpfungen zu den "echten" Objekten sind ( c:\file.txteigentlich \??\c:\file.txtmit \??\c:einem Symlink zu zB \device\harddisk0\partition1). Siehe zB hier
Matteo Italia

Antworten:


192

Da das Unix-Dateisystem viele Jahre älter ist als Windows, kann man die Frage "Warum verwendet Windows für jedes Gerät einen eigenen Bezeichner?" Umformulieren.

Ein hierarchisches Dateisystem hat den Vorteil, dass jede Datei oder jedes Verzeichnis als untergeordnetes Element des Stammverzeichnisses gefunden werden kann. Wenn Sie Daten auf ein neues Gerät oder ein Netzwerkgerät verschieben müssen, kann der Speicherort im Dateisystem gleich bleiben und die Anwendung erkennt den Unterschied nicht.

Angenommen, Sie haben ein System mit statischem Betriebssystem und einer Anwendung mit hohen E / A-Anforderungen. Sie können / usr schreibgeschützt einhängen und / opt (sofern die App dort vorhanden ist) auf SSD-Laufwerke setzen. Die Dateisystemhierarchie ändert sich nicht. Unter Windows ist dies viel schwieriger, insbesondere bei Anwendungen, die darauf bestehen, unter C: \ Programme \ zu leben.


27
Und diese (rhetorische) Frage hat eine Antwort: Tradition. Nur eine andere Tradition als Unix kam aus. Windows bezieht dies von DOS, das es von CP / M-80 bezieht, das einem gemeinsamen Muster vieler Minicomputer- und Mainframe-Betriebssysteme folgte. Die Laufwerksnamen wurden gerade von DISK0:oder SY:nach gekürzt A:.
RBerteig

6
@RBerteig - vielleicht Tradition, besonders im Windows-Fall, aber Rob Pike präsentiert ein ziemlich überzeugendes Argument für Benennungsschemata im Unix-Stil in The Hideous Name, pdos.csail.mit.edu/~rsc/pike85hideous.pdf
Bruce Ediger,

13
Seit Windows NT ist es meines Erachtens möglich, ein Gerät unter Windows an einem bestimmten virtuellen Pfad zu mounten, um genau das Gleiche wie unter Unix zu erreichen, obwohl dies auf Heim-PCs ungewöhnlich ist (etwas häufiger bei Servern und Geschäftsbereitstellungen). Sie können dies als Bestätigung des Unix Way (tm) betrachten, wenn Sie möchten.
JSB ձոգչ

8
@ BruceEdiger Ich werde nicht versuchen zu argumentieren, dass DOS richtig war. Ich möchte nur darauf hinweisen, dass es einen Zusammenhang gibt, warum Windows so ist, wie es ist, und dass es nicht nur etwas ist, das MS aus dem Hut gezogen hat.
RBerteig

1
@ BruceEdiger: Wow. Schönes Papier. Es ist auch eines der wenigen Male, bei denen ich gesehen habe, dass Pike zweifellos in irgendetwas falsch liegt. (Das heißt, dass das ARPANET-Nameserving-System nicht skaliert werden kann. Heutzutage nennen wir es DNS und es hat sich recht gut skaliert. Die Kernkonzepte eines absoluten hierarchischen Raums mit Autorität und Delegation bleiben vollständig unverändert.) Zugegebenermaßen liegt dies daran, dass Nicht-IP-Netzwerke, die für E-Mails relevant sind, ausgestorben sind.
Kevin Cathcart

87

Dies ist teils aus historischen Gründen, teils weil es auf diese Weise sinnvoller ist.

Multics

Multics war das erste Betriebssystem, das das heutige hierarchische Dateisystem mit Verzeichnissen eingeführt hat, die Verzeichnisse enthalten können. Unter Bezugnahme auf „Ein universelles Dateisystem für die Sekundärspeicherung“ von RC Daley und PG Neumann:

In Abschnitt 2 des Papiers wird die hierarchische Struktur der Dateien vorgestellt, die eine flexible Nutzung des Systems ermöglicht. Diese Struktur enthält ausreichende Fähigkeiten, um die Vielseitigkeit sicherzustellen. (…)

Zum leichteren Verständnis kann die Dateistruktur als ein Baum von Dateien angesehen werden, von denen einige Verzeichnisse sind. Das heißt, mit einer Ausnahme wird jede Datei (z. B. jedes Verzeichnis) von genau einem Zweig in genau einem Verzeichnis direkt angesprochen. Die Ausnahme ist das Stammverzeichnis (root) im Stammverzeichnis des Baums. Obwohl von keinem Verzeichnis explizit darauf verwiesen wird, wird implizit auf die Wurzel durch einen fiktiven Zweig verwiesen, der dem Dateisystem bekannt ist. (…)

Zu jeder Zeit wird davon ausgegangen, dass ein Benutzer in einem Verzeichnis arbeitet, das als sein Arbeitsverzeichnis bezeichnet wird. Er kann auf eine Datei zugreifen, auf die durch einen Eintrag in seinem Arbeitsverzeichnis effektiv verwiesen wird, indem er einfach den Eintragsnamen angibt. Es kann sein, dass mehrere Benutzer gleichzeitig dasselbe Arbeitsverzeichnis haben.

Wie in vielen anderen Aspekten suchte Multics nach Flexibilität. Benutzer können in einem Teilbaum des Dateisystems arbeiten und den Rest ignorieren und trotzdem von Verzeichnissen profitieren, um ihre Dateien zu organisieren. Verzeichnisse wurden auch für die Zugriffskontrolle verwendet - das READ-Attribut ermöglichte es Benutzern, die Dateien in einem Verzeichnis aufzulisten, und das EXECUTE-Attribut ermöglichte es Benutzern, auf Dateien in diesem Verzeichnis zuzugreifen (dies lebte, wie viele andere Funktionen, unter Unix).

Multics folgte auch dem Prinzip, einen einzigen Speicherpool zu haben. Das Papier geht nicht auf diesen Aspekt ein. Ein einziger Speicherpool passte gut zur Hardware der damaligen Zeit: Es gab keine austauschbaren Speichergeräte, zumindest keine, die den Benutzern etwas ausmachten würden. Multics verfügte zwar über einen separaten Sicherungsspeicherpool, dieser war jedoch für die Benutzer transparent.

Unix

Unix ließ sich von Multics inspirieren, zielte jedoch auf Einfachheit, wohingegen Multics auf Flexibilität abzielte.

Ein einziges hierarchisches Dateisystem passte gut zu Unix. Wie bei Multics waren Speicherpools für Benutzer normalerweise nicht relevant. Es gab jedoch Wechseldatenträger, die von Unix über die Befehle mountund für Benutzer umountverfügbar gemacht wurden (reserviert für den „Superuser“, dh den Administrator). Dennis Ritchie und Ken Thompson erklären in „The UNIX Time-Sharing System“ :

Obwohl das Stammverzeichnis des Dateisystems immer auf demselben Gerät gespeichert ist, muss sich nicht die gesamte Dateisystemhierarchie auf diesem Gerät befinden. Es gibt eine Mount-Systemanforderung mit zwei Argumenten: dem Namen einer vorhandenen normalen Datei und dem Namen einer speziellen Datei, deren zugeordnetes Speichervolumen (z. B. ein Plattenpaket) die Struktur eines unabhängigen Dateisystems mit einer eigenen Verzeichnishierarchie haben soll . Durch das Einhängen wird bewirkt, dass Verweise auf die bisher übliche Datei auf das Stammverzeichnis des Dateisystems auf dem Wechseldatenträger verweisen. Tatsächlich ersetzt mount ein Blatt des Hierarchiebaums (die normale Datei) durch einen neuen Teilbaum (die auf dem Wechseldatenträger gespeicherte Hierarchie). Nach dem Mounten gibt es praktisch keine Unterscheidung zwischen Dateien auf dem Wechseldatenträger und Dateien im permanenten Dateisystem. In unserer Installation befindet sich das Stammverzeichnis beispielsweise auf einer kleinen Partition eines unserer Festplattenlaufwerke, während das andere Laufwerk, das die Dateien des Benutzers enthält, durch die Systeminitialisierungssequenz bereitgestellt wird. Ein anbringbares Dateisystem wird durch Schreiben auf die entsprechende spezielle Datei generiert. Mit einem Hilfsprogramm können Sie ein leeres Dateisystem erstellen oder einfach ein vorhandenes Dateisystem kopieren.

Das hierarchische Dateisystem hat auch den Vorteil, dass die Komplexität der Verwaltung mehrerer Speichergeräte im Kernel konzentriert wird. Dies bedeutete, dass der Kernel komplexer war, aber alle Anwendungen dadurch einfacher wurden. Da sich der Kernel um Hardwaregeräte kümmern muss, die meisten Anwendungen dies jedoch nicht tun, ist dies ein natürlicheres Design.

Windows

Windows geht auf zwei Abstammungslinien zurück: VMS , ein Betriebssystem, das ursprünglich für den VAX- Minicomputer entwickelt wurde, und CP / M , ein Betriebssystem, das für frühe Intel-Mikrocomputer entwickelt wurde.

VMS hatte ein verteiltes hierarchisches Dateisystem, Files-11 . In Files-11 enthält der vollständige Pfad zu einer Datei einen Knotennamen, eine Kontenbezeichnung auf diesem Knoten, einen Gerätenamen, einen Verzeichnisbaumpfad, einen Dateinamen, einen Dateityp und eine Versionsnummer. VMS verfügte über eine leistungsstarke Funktion für logische Namen , mit der Verknüpfungen zu bestimmten Verzeichnissen definiert werden konnten, sodass sich Benutzer selten um den „tatsächlichen“ Speicherort eines Verzeichnisses kümmern mussten.

CP / M wurde für Computer mit 64 KB RAM und einem Diskettenlaufwerk entwickelt, daher wurde es der Einfachheit halber verwendet. Es gab keine Verzeichnisse, aber ein Dateiverweis könnte eine Laufwerksangabe ( A:oder B:) enthalten.

Als MS-DOS 2.0 Verzeichnisse einführte, tat es dies mit einer Syntax, die mit MS-DOS 1 kompatibel war, das selbst CP / M folgte. So wurzelten Pfade auf einem Laufwerk mit einem einzigen Buchstaben. (Außerdem wurde das Schrägstrichzeichen /in VMS und CP / M zum Starten von Befehlszeilenoptionen verwendet, sodass ein anderes Zeichen als Verzeichnisseparator verwendet werden musste. Aus diesem Grund verwenden DOS und spätere Windows den umgekehrten Schrägstrich, obwohl einige interne Komponenten auch Schrägstriche unterstützen ).

Windows behielt die Kompatibilität mit DOS und dem VMS-Ansatz bei, sodass die Laufwerksbuchstaben beibehalten wurden, auch wenn sie weniger relevant waren. Heute verwendet Windows unter der Haube UNC- Pfade ( ursprünglich von Microsoft und IBM für OS / 2 entwickelt , verwandter Herkunft). Obwohl dies (wahrscheinlich aufgrund des Gewichts des Verlaufs) für Hauptbenutzer reserviert ist, ermöglicht Windows die Bereitstellung über Analysepunkte .


3
Obwohl dies nicht das Standardverhalten ist, kann Windows mit NTFS-Dateisystemen auch Ihren gesamten Speicher unter einem einzigen Stammverzeichnis bereitstellen : technet.microsoft.com/en-us/library/cc753321.aspx howtogeek.com/98195/… serverfault.com/questions / 24400 /…
gerlos

3
Es scheint, dass der relevante Teil ist, dass MS-DOS 1.0 auf Diskette basierte. Auf einem solchen System (a) war es wichtig , zu wissen , welche physischen Datenträger Ihre Dateien auf waren, und (b) A:und B:war ein ordentliches Abkommen zwischen Ihrer Diskettenlaufwerke für die Unterscheidung , wenn Sie zwei von ihnen hatten. Wenn in MS-DOS 2.0 Festplattenunterstützung hinzugefügt wurde, ermöglichte die Laufwerksbezeichnung C:Abwärtskompatibilität, indem die Festplatte als eine große Diskette behandelt wurde.
user1024

5
Ursprünglich war CP / M so konzipiert, dass es in 16 KB RAM und nicht in 64 KB RAM ausgeführt wird. Die 64-KB-Zahl ist wahrscheinlich, um den Anwendungen etwas Luft zum Atmen zu lassen. Während der Befehlsprozessor (Command Processor, CCP) überschrieben und bei Bedarf neu geladen wurde, waren BIOS und BDOS zu jeder Zeit speicherresident. Ja, da kommt das BIOS her - IBM hat sich den Begriff nicht ausgedacht! Siehe Wikipedia CP / M: Hardwaremodell und Komponenten des Betriebssystems . Beachten Sie, dass 16 KB nur etwa drei dicht geschriebene Seiten sind (70 Zeilen × 80 Zeichen / Zeile × 3 Seiten = 16800 Byte).
ein CVn

36

Es gibt keine Sicherheitsbedenken, wenn ein einzelner Verzeichnisbaum vorhanden ist.

Die Entwickler von Unix verfügten über umfangreiche Erfahrungen mit Betriebssystemen, bei denen die Benutzer wissen mussten, auf welchem ​​physischen Gerät sich eine bestimmte Ressource befand. Da ein Teil des Zwecks eines Betriebssystems darin besteht, eine abstrakte Maschine auf der realen Hardware zu erstellen, hielten sie es für viel einfacher, auf die Adressierung von Ressourcen durch ihren physischen Standort zu verzichten, und beschlossen, alles in einem einzigen Namensbaum zusammenzufassen.

Dies ist nur ein Teil des Genies hinter dem Design von Unix .


28

Beachten Sie, dass die Laufwerksbuchstabennamen von MS-DOS, die in modernen Windows bestehen, hier ein roter Hering sind. Laufwerkbuchstaben sind nicht die beste Darstellung einer Dateisystemstruktur mit mehreren Wurzeln. Sie sind eine Strawman-Implementierung eines solchen Systems.

Ein richtig implementiertes Dateisystem, das mehrere Roots unterstützt, würde eine beliebige Benennung für die Volumes ermöglichen, wie z dvdrom:/path/to/file.avi. Ein solches System würde die lächerlichen Probleme mit der Benutzeroberfläche beseitigen, die Windows plagen. Wenn Sie beispielsweise ein Gerät wie eine Kamera anschließen, werden Sie in der Windows Explorer-Benutzeroberfläche darauf hingewiesen, dass es ein Gerät mit dem Namen Kamera (oder was auch immer) gibt und dass Sie einen Pfad wie diesen haben Computer\Camera\DCIM\.... Wenn Sie jedoch die Textversion dieses Pfads aus dem Explorer ausschneiden und einfügen, funktioniert dies nicht, da einige der Pfadnamenkomponenten eine Fiktion der Benutzeroberfläche sind, die dem zugrunde liegenden Betriebssystem nicht bekannt ist. In einem richtig implementierten System mit mehreren Wurzeln wäre es in Ordnung: Es gäbe einecamera:\DCIM\...Pfad, der auf jeder Ebene des Systems einheitlich erkannt wird. Wenn Sie eine alte Festplatte von einem alten PC aus portieren würden, würden Sie nicht an einen Laufwerksbuchstaben gebunden sein F:, sondern könnten diesen nach Belieben benennen old-disk:.

Wenn also Unix mehrere Roots in der Dateisystemstruktur hätte, würde dies problemlos und nicht wie in MS-DOS und Windows mit Laufwerksnamen mit einem Buchstaben erfolgen. Mit anderen Worten, lassen Sie uns das Unix-Schema nur mit einem guten Multi-Root-Design vergleichen.

Warum hat Unix also keine vernünftige Implementierung mit mehreren Wurzeln anstelle einer vernünftigen Implementierung mit einer Wurzel? Es ist wahrscheinlich nur der Einfachheit halber. Bereitstellungspunkte bieten die gesamte Funktionalität, um über Namen auf Volumes zugreifen zu können. Es ist nicht erforderlich, den Namespace mit einer zusätzlichen Präfixsyntax zu erweitern.

Mathematisch gesehen kann jeder nicht zusammenhängende Baumgraph ("Wald") verbunden werden, indem ein Wurzelknoten hinzugefügt und die nicht zusammenhängenden Teile zu seinen untergeordneten Elementen gemacht werden.

Darüber hinaus ist es flexibler, dass sich die Volumes nicht auf der Root-Ebene befinden müssen. Da es keine spezielle Syntax gibt, die das Volume bezeichnet (es ist nur eine Pfadkomponente), können Mount-Punkte überall sein. Wenn Sie in drei alten Platten auf Ihren Rechner mitbringen, können Sie sie als haben /old-disk/one, /old-disk/twousw. können Sie Festplatten organisieren , wie Sie wollen, wie Sie Dateien und Verzeichnisse organisieren.

Es können Anwendungen geschrieben werden, die von Pfaden abhängen, und die Gültigkeit von Pfaden kann beibehalten werden, wenn die Speichergeräte neu konfiguriert werden. Beispielsweise können Anwendungen bekannte Pfade wie /var/logund verwenden /var/lib. Es liegt an Ihnen, ob /var/logund /var/libauf demselben Datenträger oder auf separaten Datenträgern. Sie können ein System unter Beibehaltung der Pfade auf eine neue Speichertopologie migrieren.

Bereitstellungspunkte sind eine gute Idee. Aus diesem Grund gibt es sie seit Windows 2000.

Volume-Bereitstellungspunkte sind robust gegenüber Systemänderungen, die beim Hinzufügen oder Entfernen von Geräten zu einem Computer auftreten. Microsoft Technet


6
Vielleicht klingt Ihr "gutes Multi-Root-Design" eher nach dem alten AmigaDOS- System, das beliebige Volume-Namen zuließ, einschließlich "zugewiesener" Volumes, die auf ein bestimmtes Verzeichnis in einem anderen Volume verweisen. Sie könnten sogar (mit entsprechender Software ) "virtuelle" Volumes haben, wie beispielsweise ein FTP:Volume, mit dem Sie auf Dateien auf einem beliebigen FTP-Server mit einem Pfad wie diesem zugreifen können FTP:hostname/path/to/file.
Ilmari Karonen

3
Dies ist wirklich keine gute Antwort, da es äußerst subjektiv zu sein scheint. Es ist ein ziemlich offenes Windows-Bashing.
Rig

3
@Rig Auch wenn dies zutrifft, verdient Windows eine gründliche Bashing-Prozedur, da diese Laufwerksbuchstaben immer noch auf MS-DOS zurückgehen. Dies ist das Multi-Root-Dateisystem, mit dem die meisten Benutzer vertraut sind, aber wir können es nicht wirklich zum Vergleich mit Single-Root verwenden, da es ein Strohmann-Beispiel für ein solches System ist.
Kaz

3
@ Kaz Ich finde immer noch, dass diese Antwort eher ein Scherz ist. Windows macht das Dateisystem anders, aber es macht es nicht falsch, schrecklich oder ein Verbrechen gegen die Menschlichkeit. Sie mögen es nicht, wie Sie berechtigt sind. Microsoft hat sich dieses Schema nicht einmal ausgedacht, es wurde von einem gängigen System ausgeliehen, aber es muss gewartet werden, um eine angemessene Wartbarkeit mit altem Code zu gewährleisten.
Rig

1
@ Rig Sicher; Es ist nicht schlimmer, als zum Beispiel Ihr nächstes Abendessen mit einer Feuersteinpfeilspitze zu bekommen. Feuersteinpfeilspitzen waren in ihrer Blütezeit eigentlich Stand der Technik . Ah, aber hoppla, das können wir eigentlich nicht über DOS und Laufwerksbuchstaben sagen, können wir ... soviel zu Analogien.
Kaz

13

Sowohl * nix als auch Windows mounten ihre Laufwerke. In Windows werden diese automatisch an Bereitstellungspunkten bereitgestellt, die standardmäßig in aufsteigender alphabetischer Reihenfolge sind. Diese Standardeinstellungen sind:

  • A:und B:=> Disketten
  • C: => erste Partition der ersten Festplatte
  • D: => nächste Partition oder nächste Festplatte oder CD / DVD-Laufwerk, wenn keine anderen Partitionen vorhanden sind.

Jeder dieser Mountpunkte ist ein Verzeichnis.

In * nix werden die Einhängepunkte vom Benutzer festgelegt. Zum Beispiel habe ich eine Partition gemountet als /und eine andere als /home. Wenn /homees sich also um ein separates Laufwerk handelt, entspricht dies beispielsweise E:Windows.

In beiden Fällen, Windows und * nix, sind Bereitstellungspunkte separate Verzeichnisse. Der einzige Unterschied besteht darin, dass in * nix diese separaten Verzeichnisse Unterverzeichnisse von sind /, C:während in Windows jeder Einhängepunkt direkt unter dem eingebunden ist, sagen wir mal /unter My Computer.

Aus Sicht des Benutzers besteht der Hauptvorteil darin, dass die Halterungen vollständig transparent sind. Ich muss nicht wissen, dass sich das Verzeichnis /hometatsächlich auf einer separaten Partition befindet. Ich kann es einfach als normales Verzeichnis verwenden. Stattdessen müsste ich es unter DOS explizit mit dem Namen des Einhängepunkts aufrufenE:\home

Externe Laufwerke werden in beiden Systemen auf die gleiche Weise gemountet. Sprich D:für Windows und /mnt/cdromfür Linux. Jedes von diesen ist ein Verzeichnis, ich sehe den Unterschied nicht wirklich. Wenn Sie unter Windows eine CD-ROM in Ihr Laufwerk einlegen, wird der Datenträger D:wie unter Linux eingehängt .


3
Wissen Sie aus Neugier, was passieren würde, wenn jemand 27 Laufwerke unter Windows erstellen möchte? Wie würde Windows das 27. Laufwerk nennen? : D
Joseph R.

2
Hahaha. Scheint, Windows ist zu langweilig, um das zu tun.
Joseph R.

3
Kleiner Fehler: Die Laufwerksbuchstaben in Windows werden standardmäßig in aufsteigender alphabetischer Reihenfolge angezeigt , sie können jedoch umbenannt werden und werden häufig umbenannt.
RBerteig

3
@terdon: Er hat das Laufwerk einfach in ein Verzeichnis eingebunden - genau wie in POSIX-Betriebssystemen.
Matteo Italia

3
@JosephR: Irgendwann - ich bin mir nicht sicher, wann, aber wahrscheinlich NT - hat Windows die Möglichkeit erhalten, Laufwerke in Verzeichnissen zu mounten, ähnlich wie es Unix tut. Standardmäßig macht das eigentlich niemand (was mich überrascht: Mit der Häufigkeit von Nuke-and-Pave-Neuinstallationen würde ich denken, dass etwas, das dem Einstellen von / home auf einem separaten Volume entspricht, mittlerweile populär geworden wäre). Wenn Sie jedoch keine Laufwerksbuchstaben / -nummern / -symbole mehr haben, müssen Sie diese Schritte ausführen, um dem System weitere Laufwerke hinzuzufügen.
The Spooniest

10

Ich stimme den obigen Antworten zu, insbesondere der Antwort von Doug O'Neal, aber ich denke, dass sie alle etwas vermissen, ebenso wie die expliziten Geräteeinhängepunkte wie MS-DOS "C:" oder "A:".

Rob Pike schrieb The Hideous Name über die Syntax von Namen, aber Russ Cox brachte es auf den Punkt :

Namensräume ... sind am leistungsfähigsten, wenn neue Semantiken hinzugefügt werden können, ohne dass eine neue Syntax hinzugefügt werden muss.

Ein einziger Namensraum, in dem Geräte beliebig eingehängt werden können, ermöglicht einen wirklich flexiblen Betrieb. Ich benutze /mnt/sdb1und lege regelmäßig /mnt/cdromeine momentan nicht benutzte Diskette oder CD in das gesamte Dateisystem. Es ist überhaupt nicht ungewöhnlich, dass sich Privatverzeichnisse auf einem NFS-Server befinden, sodass Sie unabhängig davon, auf welchem ​​Computer Sie sich anmelden, $HOMEüberall dasselbe erhalten .

Es kommt darauf an: Eine spezielle Syntax für besondere Dinge setzt Ihnen bestimmte Grenzen. Wenn Sie nur eine unbenutzte Festplatte oder CD oder DVD oder ein Netzwerkdateisystem / "share" auf "E:" oder "W:" oder was auch immer mounten können, haben Sie viel weniger Flexibilität.


1
Dafür braucht man eigentlich keine Symlinks. Sie können eine Partition (oder einen Netzwerkspeicher oder was auch immer) direkt auf einem beliebigen Pfad bereitstellen, z. B. / usr / local - obwohl es mich immer verwirrt, wenn ich ein Netzwerk finde, in dem / usr / local auf eine Netzwerkbereitstellung verweist. Ja, es gibt sie und es gibt einen Grund dafür: / usr / local ist einer der Standardorte, an denen Ihr Administrator Dinge ablegt, die nicht vom Betriebssystem-Distributor stammen.
Christopher Creutzig

@Christopher Creutzig - einverstanden, symbolischer Link für mein Beispiel nicht erforderlich, ich wollte nur ein weiteres Beispiel einbringen, wie ein flexibles Namensschema für Sie funktionieren kann. Es ist vielleicht nicht das beste Beispiel.
Bruce Ediger

Schauen Sie sich übrigens das blöde Netz an. proto://specifichost.domain.tld/topleveldir/middle/specificdoc.html.
Kaz

2
@Christopher Creutzig - Ich habe / usr / local an einigen Stellen als Netzlaufwerk eingerichtet. "lokal" bedeutet dann lokal für den Standort, nicht für den Computer.
doneal24

3
@ Kaz, ich denke, das proto://Geschäft ist eine pragmatische Notwendigkeit. Es ist nicht zu erwarten, dass jede Software alle URI-Schemata kennt. Daher kann es hilfreich sein zu wissen, wann die Schema-ID endet und der Rest der URI beginnt.
Adrian Ratnapala

5

Das ist dumm. Windows hat auch einen einzelnen Hierarchiepunkt. Aber es ist versteckt und nicht standardisiert. Wie die meisten Dinge Fenster.

In diesem Fall handelt es sich um das Konzept "Arbeitsplatz". Das ist das Äquivalent von root (/) in Unix. Denken Sie daran, dass root ein Konzept ist, das im Kernel existiert. Du magst es oder nicht. So wie Windows den "Arbeitsplatz" behandelt. Natürlich können Sie eine Partition in Unix auf root mounten, und das ist, was die meisten Leute tun. Und viele Dinge betrachten einen bestimmten Pfad für Dinge (z. B. / etc /), aber Sie sind nicht darauf beschränkt. Hängen Sie Ihre Laufwerke auf jeden Fall in / C: / ein. Es ist dir nicht verboten, dies unter Unix zu tun.

C: \ ist kein Root in Windows, sondern der Mount-Punkt einer Partition. Welches MUSS auf der obersten Ebene "Arbeitsplatz" sein. Unter Unix können Sie eine Partition unter einem beliebigen anderen Baum mounten. Linux kann also C: eingebunden haben, /während D: eingebunden ist /mnt/d/... oder sogar /eingebunden, aber das ist schwierig und hängt davon ab, wie sich die beiden Dateisysteme beim Einbinden auf einem bereits eingebundenen Pfad verhalten.

Sie können also genau das Gleiche erreichen wie mit Windows, indem Sie sich "zwingen", dieselben Einschränkungen zu befolgen, die Windows Ihnen zufällig auferlegt.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

Dann müssten Sie die Mount-Optionen an die Boot-Optionen übergeben. da wirst du kein / etc / ... haben aber das simuliert auch die einschränkungen die fenster auferlegen, als das was es macht.


4
Windows hat eine einzige Hierarchie und sogar Bereitstellungspunkte, aber standardmäßig werden diese nicht verwendet.
Gilles

1
@ Gilles nicht sicher, ich verstehe. Wie verwendet das Anhängen jedes Treibers an den Stammknoten "Arbeitsplatz" ihn nicht standardmäßig?
gcb

5
Das ist nur die GUI-Präsentation. Dateipfade werden nicht verwendet My Computer.
Gilles

3
My Computerist der Wurzelknoten der Shell-Hierarchie. Es enthält Laufwerke, sofern sie einen Laufwerksbuchstaben haben , aber auch die Systemsteuerung und alle verbundenen Windows Phone-Geräte. Die Shell-Hierarchie verwendet PIDLs anstelle von Pfaden.
MSalters

4
@gcb: Der Punkt ist, dass die Shell-Hierarchie in "normalen" Anwendungen nicht direkt verwendet werden kann. Sie können die CreateFileWeitergabe von "Arbeitsplatz" oder anderen Shell-Ordnern nicht aufrufen . Es ist eine Abstraktion, die nur von Shell-bezogenem Code verstanden wird. Alle Kernel-Aufrufe (und damit 90% der Anwendungen, da die Dateiverwaltung in den meisten Sprachen in Form von Kernel-Datei-APIs implementiert ist) wissen nichts über dieses Zeug. Die Shell-Ordner können nur verwendet werden, wenn die Programme die "Standarddialoge" (die den Shell-Namespace verstehen) verwenden und wenn ausgewählte Dateien direkt einem "echten" (= vom Kernel verstandenen) Pfad zugeordnet sind.
Matteo Italia

5

Der Grund dafür, dass Windows Laufwerksbuchstaben hat, reicht wahrscheinlich weiter zurück als Microsoft und DOS. Das Zuweisen von Buchstaben zu Wechseldatenträgern war auf IBM Systemen üblich, daher hat Microsoft möglicherweise nur die Anweisungen von IBM befolgt, indem CP / M kopiert wurde. Und anfangs hatte DOS sowieso keine Verzeichnisse.

Wenn MS-DOS auf Computern mit einem oder zwei Wechseldatenträgern und keinem festen Datenträger ausgeführt wurde, brauchte man eigentlich kein Dateisystem mit Verzeichnissen. Mit einer oder vielleicht zwei 180-Kilobyte-Festplatten hatten Sie nie genug Dateien, um sie schwer zu organisieren.

https://en.wikipedia.org/wiki/Drive_letter_assignment


1
Das ist bestenfalls ungenau. CP / M war ein paar Jahre älter als jedes Microsoft / IBM-PC-DOS (ich glaube, IBM hatte ursprünglich die Idee, CP / M für seinen "PC" zu verwenden, da es sich zu dieser Zeit trotz allem um einen ziemlich gut etablierten de-facto-Industriestandard handelte die Tatsache, dass verschiedene CP / M-Systeme inkompatibel sein könnten), und es ist kaum zu bestreiten, dass das IBM-PC-DOS stark auf 86-DOS basierte, das wiederum im Grunde ein quellcode-kompatibler Klon von CP / M war .
ein CVn

4

Tatsächlich basiert Linux auf Unix (oder Unix, siehe Diskussion ) und Unix stammt aus der Mainframe-Umgebung, in der die Verwendung mehrerer Geräte offensichtlich war. Das Mounten von Geräten in einem einzigen Verzeichnisbaum bietet Ihnen maximale Flexibilität und beschränkt nicht die Anzahl der Geräte, auf die das Betriebssystem zugreifen kann.

Auf der anderen Seite sind DOS-Buchstaben für Laufwerke ein gutes Design für einen PC mit 1 oder 2 Diskettenstationen und einem einzelnen Laufwerk. Die große Diskette 5,25 'ist immer A :, die kleine 3,5' ist immer B: und das Laufwerk ist immer C :. Sie wissen immer, ob Sie eine Datei auf die Diskette oder irgendwo auf die Diskette kopieren. Sie benötigen keine Flexibilität, wenn Sie nicht mehr als 2 Diskettenlaufwerke und 2 (oder 4) Festplatten physisch verbinden können.

DOS-Design war benutzerfreundlicher, während Unix-Design für Administratoren geeignet ist. Jetzt stellen Laufwerksbuchstaben eine Belastung für Windows dar. Benutzer verlassen sich mehr darauf, dass das Explorer-Fenster mit dem Inhalt eines Wechseldatenträgers automatisch geöffnet wird, als dass sie dessen Buchstaben kennen ... Ubuntu macht das auch.


1

Das stimmt eigentlich nicht. Windows verwendet ein anderes Pfadschema (nun ja, nicht dasselbe)

"Unit Letters" sind nur etwas, an das man sich leicht Pfade, Festplatten und Partitionen merken kann.

ARC-Pfade definieren den Pfad einer Datei in Windows (sie sind jedoch nur beim Booten für den Benutzer sichtbar):

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

In Windows NT gibt es keine Beziehung zwischen Festplatten, Partitionen und Einheitenbuchstaben: Sie können ein gesamtes Volume in einem Ordner "ablegen" (z. B .: c: \ myseconddisk könnte eine gesamte physische Festplatte sein!)


1
ARC-Pfade dienen nur zum Booten, um die Kompatibilität mit einigen ROMs zu gewährleisten, wenn NT auf Alpha und MIPS portiert wurde. Wenn das System ausgeführt wird, werden UNC-Pfade verwendet.
Ninjalj

0

Zwei Dinge, auf die ich hinweisen möchte -

  1. Festplatten in Linux werden tatsächlich in gewisser Weise Buchstaben / Namen zugewiesen, wie / dev / sdb1. Sie können jedoch überall montiert werden, um von der Single- / Root-Struktur aus erreicht zu werden
  2. Der häufigste Grund, warum Menschen (einschließlich meiner selbst in der Vergangenheit) separate Laufwerke in Windows hatten, bestand darin, Dokumente, Musik, Programme usw. an einem Ort aufzubewahren, an dem Windows unweigerlich neu installiert oder ersetzt werden musste, sei es ein Upgrade oder ein Virus oder Dateisystemfehler, es gab immer noch Zugriff auf diese Dateien. Ich habe dieses Problem nicht unter Linux - das Dateisystem ist viel zuverlässiger, das Betriebssystem bricht nur durch eine direkte Aktion oder durch einen Fehler von meiner Seite (ooh! Ein hochaktuelles Repo, lass es uns versuchen!) Und Upgrades sind viel einfacher. Und in dem seltenen Fall musste ich neu installieren, da die gesamte Software über die von mir hinzugefügten Repos oder PPAs verfügbar war (und ich mein Home-Verzeichnis problemlos mit einer Live-Festplatte kopieren konnte).

2
Sie kombinieren Festplatten und Dateisysteme in Ihrem ersten Punkt. Wenn Sie / dev / sdb1 irgendwann im Dateisystem mounten, können Sie auf die Dateien auf dem Laufwerk zugreifen. Wenn Sie / dev / sdb1 direkt öffnen, sehen Sie die Raw-Plattenblöcke. Im Allgemeinen nicht sehr nützlich, insbesondere wenn Sie verschlüsselte Dateisysteme verwenden.
doneal24

Ich habe versucht, es so zu beschreiben, dass Windows-Benutzer es vielleicht verstehen. C: Auch unter Windows ist es keine Festplatte, aber alle bezeichnen es als
solche

1.Sie können Ihre Dateien weiterhin ohne Buchstaben aufbewahren. 2. In POSIX-Systemen kann eine Festplatte als Ganzes ohne Partitionstabelle partitioniert werden, und ein Thumb-Laufwerk kann eine Partitionstabelle haben. Wir haben sogar FS in einer Datei anstelle einer Aktentasche, die nur derjenige kennt, der die Partition erstellt hat Name.
Behrooz

0

Wenn Sie in die Geschichte zurückblicken, können Sie auch feststellen, dass Unix zur Zeit von 8-Spur-Bandsystemen für Audio und 9-Spur-IBM-Datensystemen (8 Spuren / 8 Bits für Daten, eine für Parität) gestartet wurde. Technisch sehr ähnlich.

Zu diesem Zeitpunkt wurden die Informationen über den Speicherort von Dateien in Teilen der Informationen auf Band gespeichert und vorwärts und rückwärts definiert, wenn Sie Daten vom Band lesen (wie eine Datei mit Anfangsposition und Endsignatur). Dies erklärt auch, warum Sie zu Beginn des Laufwerks nicht nur eine FAT hatten - Sie hatten mehrere, um die Suche zu beschleunigen. Und wenn Sie mehrere Laufwerke hatten, wurden diese innerhalb von / dev und über die Adresse der Datei, die Sie zwischen den Geräten verschoben haben, verknüpft.

Ich glaube, Sie könnten die Ansicht haben, dass es einfach früher angefangen hat und dass die Entscheidung hinter MS Dos (CP / M) und später Windows NT einfach mit den Laufwerksbuchstaben von VM-Mainframes zusammenhängt, anstatt mit einem einzigen Einstiegspunkt, denn zu der Zeit sah es so aus moderner, Datenmengen von heute existierten nicht und sie dachten nicht, dass Sie schließlich nicht genug Laufwerksbuchstaben haben würden oder dass es überladen wäre.

9-Spur-Laufwerk und Laufwerksbuchstabenzuordnung

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.