¿Por qué el sistema de archivos de Linux está diseñado como un único árbol de directorios?

91

¿Alguien puede explicar por qué Linux está diseñado como un único árbol de directorios?

Mientras que en Windows podemos tener múltiples unidades como C:\, y D:\, hay una sola raíz en Unix. ¿Alguna razón específica allí?

usuario2720323
fuente
14
@terdon - Creo que está preguntando acerca de tener un solo directorio raíz (/) vs. estilo DOS (C: \ D: \).
jordanm
27
También puede (y generalmente lo hace) tener múltiples unidades en Linux. De hecho, el principio básico es el mismo, C:y también D:son puntos de montaje en Windows. El equivalente de Windows /es My Computer, todo está montado debajo de eso.
terdon
61
Creo que una pregunta más relevante sería "¿por qué un sistema operativo NO tendría una sola raíz"? (La respuesta para DOS / Windows sería un error de diseño / falta de planificación para el futuro / suposición innecesaria)
JoelFan
21
Windows eligió ese sistema extraño debido a MS-DOS anterior, y MS-DOS siguió el precedente anterior establecido por CP / M. MS-DOS era un sistema basado en unidad de disquete (A: y B: inicialmente, a veces, por ejemplo, en un sistema de unidad única, A: y B: eran la misma unidad, pero dos discos lógicos diferentes para fines de operación de intercambio / copia) . Como la mayoría de las personas dañadas por las PC con MS-DOS, el OP piensa que /en Linux es lo mismo que C: en MSDOS / Windows, cuando en realidad no es lo mismo.
Warren P
25
En realidad, C:, D:y esas cosas es sólo la compatibilidad con DOS y Win32; Windows NT internamente tiene una jerarquía de objetos similar a UNIX, donde las letras de unidad (y en general cosas de Win32) son solo enlaces simbólicos a los objetos "reales" (en c:\file.txtrealidad \??\c:\file.txt, es \??\c:ser un enlace simbólico, por ejemplo \device\harddisk0\partition1). Ver, por ejemplo, aquí
Matteo Italia

Respuestas:

192

Dado que el sistema de archivos Unix es anterior a Windows por muchos años, uno puede reformular la pregunta a "¿por qué Windows usa un designador separado para cada dispositivo?".

Un sistema de archivos jerárquico tiene la ventaja de que cualquier archivo o directorio se puede encontrar como hijo del directorio raíz. Si necesita mover datos a un nuevo dispositivo o dispositivo de red, la ubicación en el sistema de archivos puede permanecer igual y la aplicación no verá la diferencia.

Suponga que tiene un sistema donde el sistema operativo es estático y hay una aplicación que tiene altos requisitos de E / S. Puede montar / usr solo lectura y poner / optar (si la aplicación vive allí) en unidades SSD. La jerarquía del sistema de archivos no cambia. En Windows, esto es mucho más difícil, particularmente con aplicaciones que insisten en vivir bajo C: \ Archivos de programa \

doneal24
fuente
27
Y esa pregunta (retórica) tiene una respuesta: tradición. Solo una tradición diferente de la que vino Unix. Windows obtiene esto de DOS, que lo obtiene de CP / M-80, que siguió un patrón común de muchos sistemas operativos de miniordenador y mainframe. Los nombres de las unidades se acortaron de DISK0:o SY:hacia A:.
RBerteig
66
@RBerteig: tal vez tradición, especialmente en el caso de Windows, pero Rob Pike presenta un argumento bastante convincente para los esquemas de nombres de estilo Unix en The Hideous Name, pdos.csail.mit.edu/~rsc/pike85hideous.pdf
Bruce Ediger
13
Desde Windows NT, creo, ha sido posible montar un dispositivo en una ruta virtual dada en Windows para lograr exactamente lo mismo que Unix, aunque es poco común en las PC domésticas (algo más común en servidores e implementaciones comerciales). Si lo desea, puede ver esto como una reivindicación de Unix Way (tm).
JSB ձոգչ
8
@BruceEdiger No voy a tratar de argumentar que DOS tenía razón. Simplemente señalando que hay un contexto de por qué Windows es como es, y que no fue solo algo que MS sacó de un sombrero.
RBerteig
1
@BruceEdiger: Wow. Buen papel También es una de las pocas veces que he visto a Pike estar indudablemente equivocado sobre algo. (Es decir, que el sistema de servicio de nombres ARPANET no puede escalar. En estos días lo llamamos DNS, y ha escalado bastante bien. Los conceptos centrales de un espacio hierático absoluto con autoridad y delegación permanecen completamente sin cambios). Es cierto que esto se debe a que las redes no IP que son relevantes para el correo se han extinguido.
Kevin Cathcart
87

Esto es en parte por razones históricas, y en parte porque tiene más sentido de esta manera.

Multics

Multics fue el primer sistema operativo en introducir el sistema de archivos jerárquico tal como lo conocemos hoy, con directorios que pueden contener directorios. Citando "Un sistema de archivos de uso general para almacenamiento secundario" por RC Daley y PG Neumann:

La Sección 2 del documento presenta la estructura jerárquica de los archivos, lo que permite un uso flexible del sistema. Esta estructura contiene capacidades suficientes para garantizar la versatilidad. (...)

Para facilitar la comprensión, la estructura de archivos puede considerarse como un árbol de archivos, algunos de los cuales son directorios. Es decir, con una excepción, cada archivo (por ejemplo, cada directorio) se encuentra directamente señalado por exactamente una rama en exactamente un directorio. La excepción es el directorio raíz, o raíz, en la raíz del árbol. Aunque no se señala explícitamente desde ningún directorio, la raíz se señala implícitamente mediante una rama ficticia que el sistema de archivos conoce. (...)

En cualquier momento, se considera que un usuario está operando en algún directorio, llamado su directorio de trabajo. Puede acceder a un archivo efectivamente señalado por una entrada en su directorio de trabajo simplemente especificando el nombre de la entrada. Más de un usuario puede tener el mismo directorio de trabajo a la vez.

Como en muchos otros aspectos, Multics buscó flexibilidad. Los usuarios pueden trabajar en un subárbol del sistema de archivos e ignorar el resto, y aún así beneficiarse de los directorios para organizar sus archivos. Los directorios también se usaron para el control de acceso: el atributo READ permitió a los usuarios enumerar los archivos en un directorio, y el atributo EXECUTE permitió a los usuarios acceder a los archivos en ese directorio (esto, como muchas otras características, vivía en Unix).

Multics también siguió el principio de tener un único grupo de almacenamiento. El documento no se detiene en este aspecto. Un único grupo de almacenamiento era una buena combinación con el hardware de la época: no había dispositivos de almacenamiento extraíbles, al menos ninguno que a los usuarios les importara. Multics tenía un grupo de almacenamiento de respaldo separado, pero esto era transparente para los usuarios.

Unix

Unix se inspiró mucho en Multics, pero apuntó a la simplicidad, mientras que Multics apuntó a la flexibilidad.

Un único sistema de archivos jerárquico se adaptaba bien a Unix. Al igual que con Multics, los grupos de almacenamiento generalmente no eran relevantes para los usuarios. Sin embargo, había dispositivos extraíbles, y Unix los expuso a los usuarios, a través de los comandos mounty umount(reservados para el "superusuario", es decir, el administrador). En "El sistema de tiempo compartido UNIX" , Dennis Ritchie y Ken Thompson explican:

Aunque la raíz del sistema de archivos siempre se almacena en el mismo dispositivo, no es necesario que toda la jerarquía del sistema de archivos resida en este dispositivo. Hay una solicitud de sistema de montaje con dos argumentos: el nombre de un archivo ordinario existente y el nombre de un archivo especial cuyo volumen de almacenamiento asociado (por ejemplo, un paquete de disco) debe tener la estructura de un sistema de archivos independiente que contenga su propia jerarquía de directorios . El efecto de mount es hacer que las referencias al archivo ordinario hasta ahora se refieran al directorio raíz del sistema de archivos en el volumen extraíble. En efecto, mount reemplaza una hoja del árbol de jerarquía (el archivo ordinario) por un subárbol completamente nuevo (la jerarquía almacenada en el volumen extraíble). Después del montaje, prácticamente no hay distinción entre los archivos en el volumen extraíble y los del sistema de archivos permanente. En nuestra instalación, por ejemplo, el directorio raíz reside en una pequeña partición de una de nuestras unidades de disco, mientras que la otra unidad, que contiene los archivos del usuario, está montada por la secuencia de inicialización del sistema. Un sistema de archivos montable se genera escribiendo en su archivo especial correspondiente. Un programa de utilidad está disponible para crear un sistema de archivos vacío, o uno simplemente puede copiar un sistema de archivos existente.

El sistema de archivos jerárquico también tiene la ventaja de concentrar la complejidad de administrar múltiples dispositivos de almacenamiento en el núcleo. Esto significaba que el núcleo era más complejo, pero como resultado todas las aplicaciones eran más simples. Dado que el núcleo tiene que preocuparse por los dispositivos de hardware, pero la mayoría de las aplicaciones no, este es un diseño más natural.

Ventanas

Windows remonta su ascendencia a dos linajes: VMS , un sistema operativo diseñado originalmente para la minicomputadora VAX , y CP / M , un sistema operativo diseñado para las primeras microcomputadoras Intel.

VMS tenía un sistema de archivos jerárquico distribuido, Archivos-11 . En Files-11, la ruta completa a un archivo contiene un nombre de nodo, una designación de cuenta en ese nodo, un nombre de dispositivo, una ruta de árbol de directorio, un nombre de archivo, un tipo de archivo y un número de versión. VMS tenía una poderosa función de nombre lógico que permitía definir accesos directos a directorios específicos, por lo que los usuarios rara vez tendrían que preocuparse por la ubicación "real" de un directorio.

CP / M fue diseñado para computadoras con 64kB de RAM y una unidad de disquete, por lo que fue por simplicidad. No había directorios, pero una referencia de archivo podría incluir una indicación de unidad ( A:o B:).

Cuando MS-DOS 2.0 introdujo directorios, lo hizo con una sintaxis compatible con MS-DOS 1 que seguía a CP / M. Entonces, las rutas se enraizaron en una unidad con un nombre de una sola letra. (Además, el carácter de barra diagonal /se usó en VMS y CP / M para iniciar las opciones de línea de comandos, por lo que se tuvo que usar un carácter diferente como separador de directorio. Esta es la razón por la cual DOS y Windows usan barra diagonal inversa, aunque algunos componentes internos también admiten barra diagonal )

Windows retuvo la compatibilidad con DOS y el enfoque VMS, por lo que mantuvo la noción de letras de unidad incluso cuando se volvieron menos relevantes. Hoy, bajo el capó, Windows usa rutas UNC ( desarrolladas originalmente por Microsoft e IBM para OS / 2 , de ascendencia relacionada). Aunque esto está reservado para usuarios avanzados (probablemente debido al peso del historial), Windows permite el montaje a través de puntos de análisis .

Gilles
fuente
3
Aunque no es el comportamiento predeterminado, con los sistemas de archivos NTFS, Windows también puede montar todo su almacenamiento en una sola raíz: technet.microsoft.com/en-us/library/cc753321.aspx howtogeek.com/98195/… serverfault.com/questions / 24400 /…
gerlos
3
Parece que la parte relevante es que MS-DOS 1.0 estaba basado en disquete. En dicho sistema, (a) era importante saber en qué disco físico estaban sus archivos, y (b) A:y B:era una convención decente para distinguir entre sus unidades de disquete si tenía dos de ellas. Cuando se agregó compatibilidad con el disco duro en MS-DOS 2.0, la C:designación del disco permitió la compatibilidad con versiones anteriores al tratar el HD como un gran disquete.
usuario1024
55
En realidad, inicialmente CP / M fue diseñado para ejecutarse en 16 , no en 64 KB de RAM. La cifra de 64 KB probablemente permita que las aplicaciones tengan algo de espacio para respirar; mientras que el procesador de comandos (CCP) se sobrescribió y se volvió a cargar si fuera necesario, BIOS y BDOS eran residentes de memoria en todo momento. Sí, de ahí viene el BIOS: ¡IBM no se le ocurrió el término! Consulte Wikipedia CP / M: Modelo de hardware y componentes del sistema operativo . Tenga en cuenta que 16 KB son solo tres páginas densamente escritas (70 líneas × 80 caracteres / línea × 3 páginas = 16800 bytes).
un CVn
36

No hay problemas de seguridad detrás de tener un solo árbol de directorios.

Los chicos que diseñaron Unix tenían mucha experiencia con sistemas operativos que requerían que los usuarios supieran qué dispositivo físico contenía un recurso dado. Dado que parte del propósito de un sistema operativo es crear una máquina abstracta sobre hardware real, pensaron que era mucho más sencillo prescindir de los recursos de direccionamiento por su ubicación física y decidieron poner todo en un solo árbol de nombres.

Esta es solo una parte del genio detrás del diseño de Unix .

msw
fuente
28

Tenga en cuenta que los nombres de letras de unidad de MS-DOS que persisten en Windows moderno son una pista falsa aquí. Los nombres de letras de unidad no son la mejor representación de una estructura de sistema de archivos que tiene múltiples raíces. Son una implementación de paja de tal sistema.

Un sistema de archivos implementado adecuadamente que admita múltiples raíces permitiría nombrar arbitrariamente los volúmenes, como dvdrom:/path/to/file.avi. Tal sistema eliminaría los ridículos problemas de la interfaz de usuario que afectan a Windows. Por ejemplo, si conecta un dispositivo como una cámara, la IU del Explorador de Windows le hace creer que hay un dispositivo llamado Cámara (o lo que sea), y que tiene una ruta similar Computer\Camera\DCIM\.... Sin embargo, si corta y pega la versión textual de esta ruta fuera del Explorador, en realidad no funciona porque algunos de los componentes de la ruta son una ficción de interfaz de usuario, no conocida por el sistema operativo subyacente. EN un sistema implementado adecuadamente con múltiples raíces, estaría bien: habría uncamera:\DCIM\...ruta que se reconoce de manera uniforme en todos los niveles del sistema. Además, si portabas un viejo disco duro desde una PC ANTIGUA, no estarías atascado con algún nombre de letra de unidad F:, sino que podrías nombrarlo como quieras old-disk:.

Por lo tanto, si Unix tuviera múltiples raíces en la estructura del sistema de archivos, se haría de una manera sensata, y no como en MS-DOS y Windows con nombres de unidades de una letra. En otras palabras, comparemos solo el esquema Unix con un buen diseño de múltiples raíces.

Entonces, ¿por qué Unix no tiene una implementación sensata de múltiples raíces, a favor de una implementación sensata de una raíz? Probablemente sea solo por simplicidad. Los puntos de montaje proporcionan toda la funcionalidad de poder acceder a los volúmenes a través de nombres. No es necesario ampliar el espacio de nombres con una sintaxis de prefijo adicional.

Matemáticamente hablando, cualquier gráfico de árbol disjunto ("bosque") se puede unir agregando un nodo raíz y haciendo que las piezas disjuntas sean sus hijos.

Además, es más flexible que los volúmenes no tengan que estar en el nivel raíz. Como no hay una sintaxis especial que denote el volumen (es solo un componente de ruta), los puntos de montaje pueden estar en cualquier lugar. Si trae en tres discos viejos a su máquina, puede tenerlos como /old-disk/one, /old-disk/two, etc. Puede organizar los discos que le apetezca, la forma de organizar los archivos y directorios.

Se pueden escribir aplicaciones que dependen de las rutas, y la validez de las rutas se puede mantener cuando se reconfiguran los dispositivos de almacenamiento. Por ejemplo, las aplicaciones pueden usar rutas conocidas como /var/logy /var/lib. Depende de usted si está /var/logy /var/libestá en el mismo volumen de disco o en uno separado. Puede migrar un sistema a una nueva topología de almacenamiento, mientras conserva las rutas.

Los puntos de montaje son una buena idea, por eso Windows los ha tenido desde Windows 2000.

Los puntos de montaje de volumen son sólidos frente a los cambios del sistema que ocurren cuando se agregan o eliminan dispositivos de una computadora. Microsoft Technet

Kaz
fuente
66
Quizás por coincidencia, su "buen diseño de múltiples raíces" se parece mucho al antiguo sistema AmigaDOS , que permitía nombres de volumen arbitrarios, incluidos los volúmenes "asignados" que se referían a un directorio específico dentro de otro volumen. Incluso podría (con el software apropiado ) tener volúmenes "virtuales" como, por ejemplo, un FTP:volumen que le permitiera acceder a archivos en cualquier servidor FTP con una ruta como FTP:hostname/path/to/file.
Ilmari Karonen
3
Esta realmente no es una buena respuesta, ya que parece ser extremadamente subjetiva. Es bastante abiertamente el ataque de Windows.
Plataforma
3
@Rig Aunque eso puede ser cierto, Windows merece una crítica completa por seguir teniendo estos nombres de letras de unidad, que se remontan a MS-DOS. Este es el sistema de archivos de múltiples raíces con el que la mayoría de los usuarios están familiarizados, sin embargo, realmente no podemos usarlo para fines de comparación con una sola raíz, porque es un ejemplo de este tipo de sistema.
Kaz
3
@Kaz Todavía encuentro que esta respuesta es más una queja. Windows hace que el sistema de archivos sea diferente, pero no lo hace incorrecto, horrible o un crimen contra la humanidad. No te gusta como tienes derecho. Microsoft ni siquiera ideó este esquema, lo tomaron prestado de un sistema popular de la actualidad, pero tienen que mantenerlo para una mantenibilidad razonable con código heredado.
Plataforma
1
@Rig Sure; no es más horrible que, digamos, obtener su próxima cena con una punta de flecha de sílex. Las puntas de flecha de sílex eran en realidad lo último en su apogeo . Ah, pero vaya, en realidad no podemos decir eso sobre DOS y letras de unidad, ¿podemos ... tanto por analogías?
Kaz
13

Tanto * nix como Windows montan sus unidades. En Windows, estos se montan automáticamente en puntos de montaje que, de forma predeterminada, están en orden alfabético ascendente. Estos valores predeterminados son:

  • A:y B:=> disquetes
  • C: => primera partición del primer disco duro
  • D: => siguiente partición o siguiente disco duro o unidad de CD / DVD si no hay otras particiones presentes.

Cada uno de estos puntos de montaje es un directorio.

En * nix, el usuario decide los puntos de montaje. Por ejemplo, tengo una partición montada como /y otra como /home. Entonces, /homees una unidad separada, sería el equivalente de decir E:en Windows.

En ambos casos, Windows y * nix, los puntos de montaje son directorios separados. La única diferencia es que en * nix, estos directorios separados son subdirectorios de /, C:mientras que en Windows, cada punto de montaje se monta directamente debajo de /, My Computerdigamos.

Desde la perspectiva del usuario, la principal ventaja es que las monturas son completamente transparentes. No necesito saber que el directorio /homeestá realmente en una partición separada. Solo puedo usarlo como un directorio normal. En cambio, en DOS, tendría que llamarlo explícitamente por el nombre del punto de montaje, digamosE:\home

Las unidades externas se montan prácticamente de la misma manera en ambos sistemas. Digamos D:para Windows y /mnt/cdrompara Linux. Cada uno de estos es un directorio, realmente no veo la diferencia. Cuando coloca un CDROM en su unidad bajo Windows, el disco se monta D:exactamente igual que en Linux.

terdon
fuente
3
Por curiosidad, ¿sabes qué pasaría si alguien quisiera crear 27 unidades en Windows? ¿Cómo llamaría Windows a la unidad 27? : D
Joseph R.
2
Jajaja. Parece que Windows es demasiado aburrido para hacer eso.
Joseph R.
3
Nitpick menor: las letras de unidad en Windows por defecto en orden alfabético ascendente, pero pueden ser y a menudo se les cambia el nombre.
RBerteig
3
@terdon: simplemente montaría la unidad dentro de un directorio, exactamente como lo hace en los sistemas operativos POSIX.
Matteo Italia
3
@JosephR: En algún momento, no estoy seguro de cuándo, pero probablemente NT, Windows ganó la capacidad de montar unidades en directorios, al igual que Unix. Por defecto, nadie hace esto (lo que me sorprende: con la frecuencia de reinstalaciones de armas nucleares y pavimentar, creo que algo similar a poner / home en un volumen separado se habría vuelto popular por ahora). Sin embargo, si se le acaban las letras / números / símbolos de la unidad, esto es lo que debe hacer si desea agregar más unidades al sistema.
El Spooniest
10

Estoy de acuerdo con las respuestas anteriores, especialmente la respuesta de Doug O'Neal, pero creo que todos pierden algo, al igual que los puntos de montaje de dispositivos explícitos como MS-DOS "C:" o "A:".

Rob Pike escribió The Hideous Name sobre la sintaxis de los nombres, pero Russ Cox lo resumió :

Los espacios de nombres ... son más potentes cuando se pueden agregar nuevas semánticas sin agregar una nueva sintaxis.

Un espacio de nombre único donde los dispositivos se pueden montar arbitrariamente permite operaciones realmente flexibles. Regularmente uso /mnt/sdb1y /mnt/cdromcoloco temporalmente un disco o CD no utilizado actualmente en el sistema de archivos general. No es raro tener directorios de inicio en un servidor NFS, por lo que no importa en qué máquina inicie sesión, obtendrá lo mismo en $HOMEtodas partes.

Todo se reduce a esto: tener una sintaxis especial para cosas especiales pone límites definidos a lo que puede hacer. Si solo puede montar un disco o CD o DVD no utilizado, o un sistema de archivos de red / "compartir" en "E:" o "W:" o lo que sea, tendrá mucha menos flexibilidad.

Bruce Ediger
fuente
1
Realmente no necesitas enlaces simbólicos para eso. Puede montar directamente una partición (o almacenamiento de red o lo que sea) en cualquier ruta, como / usr / local, aunque siempre me desconcierta cuando encuentro una red donde / usr / local apunta a un montaje de red. Sí, existen y hay alguna razón para hacerlo: / usr / local es uno de los lugares estándar para que su administrador coloque cosas que no sean del distribuidor del sistema operativo.
Christopher Creutzig
@Christopher Creutzig: el enlace simbólico acordado no es necesario para mi ejemplo, solo quería agregar otro ejemplo de cómo un esquema de nombres flexible puede funcionar para usted. Quizás no sea el mejor ejemplo.
Bruce Ediger
Mira la estúpida web, por cierto. proto://specifichost.domain.tld/topleveldir/middle/specificdoc.html.
Kaz
2
@ Christopher Creutzig: he configurado / usr / local como una unidad de red en un par de lugares. "local" significa local para el sitio, no para la máquina.
doneal24
3
@Kaz, creo que el proto://negocio es una necesidad pragmática. No se puede esperar que cada pieza de software conozca todos los esquemas de URI que existen. Por lo tanto, puede ser útil saber cuándo termina la ID del esquema y comienza el resto del URI.
Adrian Ratnapala
5

Esto es tonto. Windows también tiene un único punto de jerarquía. Pero está oculto y no es estándar. Como la mayoría de las cosas de windows.

En este caso, es el concepto "Mi PC". Ese es el equivalente de root (/) en Unix. Recuerde que root es un concepto que existe en el kernel. Te gusta o no. Al igual que las ventanas tratan el "Mi PC". por supuesto, puedes montar una partición en root en unix, y eso es lo que hace la mayoría de la gente. Y muchas cosas mirarán una ruta específica para las cosas (por ejemplo, / etc /) pero no está limitado por ella. Por supuesto, monte sus unidades en / C: /. No está prohibido hacer eso en Unix.

C: \ no es una raíz en Windows, es el punto de montaje de una partición. Que DEBE estar en el nivel superior "Mi PC". Mientras esté en Unix, puede montar una partición debajo de cualquier otro árbol. Entonces, Linux puede tener C: montado /mientras tiene D: montado /mnt/d/... o incluso también montado, /pero eso es complicado y depende de cómo se comporten los dos sistemas de archivos al montar encima de una ruta ya montada.

Por lo tanto, puede obtener exactamente lo mismo que tiene con Windows al "forzarse" a seguir las mismas limitaciones que Windows le impone al azar.

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

Entonces tendría que pasar las opciones de montaje en las opciones de arranque. ya que no tendrás un / etc / ... pero eso también es simular las limitaciones que impone Windows, ya que eso es lo que hace.

gcb
fuente
44
Windows tiene una sola jerarquía debajo del capó, e incluso tiene puntos de montaje, pero no los usa por defecto.
Gilles
1
@Gilles no estoy seguro de entender. ¿Cómo conectar cada controlador al nodo raíz "Mi PC" no lo está usando de manera predeterminada?
gcb
55
Esa es solo la presentación de la GUI. Las rutas de archivo no se usan My Computer.
Gilles
3
My Computeres el nodo raíz de la jerarquía de Shell. contiene unidades, si tienen una letra de unidad , pero también el panel de control y cualquier Windows Phone conectado. La jerarquía de Shell utiliza PIDL en lugar de rutas.
MSalters
44
@gcb: el punto es que la jerarquía de shell no se puede usar directamente en aplicaciones "normales". No puede llamar a CreateFilepasar "Mi PC" u otras carpetas de shell; es una abstracción entendida solo por el código relacionado con el shell, todas las llamadas al kernel (y, por lo tanto, el 90% de las aplicaciones, ya que la administración de archivos en la mayoría de los idiomas se implementa en términos de API de archivos del kernel) no saben nada sobre estas cosas. Las carpetas de shell solo se pueden usar cuando los programas usan los "cuadros de diálogo estándar" (que hacen el subtema y el espacio de nombres del shell) y solo cuando los archivos seleccionados se asignan directamente a una ruta "real" (= entendida por el núcleo).
Matteo Italia
5

La razón por la cual Windows tiene letras de unidad probablemente se remonta más allá de Microsoft y DOS. La asignación de letras a unidades extraíbles era común en los sistemas de IBM, por lo que Microsoft puede haber estado actuando según las instrucciones de IBM copiando CP / M. E inicialmente, DOS no tenía directorios de todos modos.

Cuando MS-DOS se ejecutaba en computadoras con uno o dos discos extraíbles y sin medios fijos, realmente no necesitaba un sistema de archivos con directorios. Con uno, o tal vez dos, discos de 180 kilobytes, nunca tuvo suficientes archivos para tener muchos problemas para organizarlos.

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

david25272
fuente
1
Esto es inexacto en el mejor de los casos. CP / M fue anterior a cualquier Microsoft / IBM-PC DOS por varios años (creo que la idea original de IBM era usar CP / M para su "PC", ya que era un estándar industrial de facto bastante bien establecido en ese momento a pesar de el hecho de que varios sistemas CP / M podrían ser incompatibles), y no se discute que el DOS de IBM-PC se basó en gran medida en 86-DOS, que a su vez era básicamente un clon de CP / M compatible con el código fuente .
un CVn
4

En realidad, Linux se basa en Unix (o es Unix, ver discusión ) y Unix proviene del entorno de mainframe, donde el uso de múltiples dispositivos era bastante obvio. El montaje de dispositivos en un solo árbol de directorios le brinda la máxima flexibilidad y no limita la cantidad de dispositivos a los que puede acceder el sistema operativo.

Por otro lado, las letras DOS para unidades son un buen diseño para una PC con 1 o 2 estaciones de disquete y una unidad de disco individual. El disquete grande 5,25 'siempre es A :, el pequeño 3,5' siempre es B :, y la unidad de disco siempre es C :. Siempre sabe si copia un archivo en el disquete o en algún lugar del disco. No necesita ninguna flexibilidad si no puede conectar físicamente más de 2 unidades de disquete y 2 (o 4) discos duros.

El diseño de DOS fue más amigable para el usuario final, mientras que el diseño de Unix es amigable para el administrador. Ahora las letras de unidad son una carga para Windows, los usuarios confían más en abrir automáticamente la ventana del explorador con contenido de unidad extraíble que saber su letra ... Ubuntu hace lo mismo, en realidad.

Marinero danubiano
fuente
1

Eso no es cierto, en realidad. Windows usa otro esquema de rutas (bueno, no el mismo)

Las "Cartas de unidad" son solo algo para recordar fácilmente rutas, discos y particiones.

Las rutas ARC definen la ruta de un archivo en Windows (pero solo son visibles para el usuario en el arranque):

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

En Windows NT no hay relación entre discos, particiones y letras de unidad: puede "poner" un volumen completo en una carpeta (por ejemplo: c: \ myseconddisk podría ser un disco físico completo).

AndreaCi
fuente
1
Las rutas ARC son solo para el arranque, para compatibilidad con algunas ROM cuando NT fue portado a Alpha y MIPS. Cuando el sistema se está ejecutando, utiliza rutas UNC.
ninjalj
0

Dos cosas que me gustaría señalar:

  1. Los discos duros en Linux están realmente asignados a letras / nombres, como / dev / sdb1. Pero se pueden montar en cualquier lugar para llegar desde la estructura única / raíz
  2. La razón más común por la que las personas (incluyéndome a mí mismo en el pasado) tenían unidades separadas en Windows era tener un lugar para guardar documentos, música, programas, etc. falla del sistema de archivos, todavía había acceso a esos archivos. No tengo este problema en Linux: el sistema de archivos es mucho más confiable, el sistema operativo no se rompe a menos que sea por alguna acción directa o error de mi parte (¡ooh! ¡Un repositorio de última generación, intentemos eso!) Y actualizaciones son MUCHO más simples. Y, en el raro caso que tuve que reinstalar, ya que todo el software estaba disponible a través de repos o ppa's que agregué (y podía copiar fácilmente mi directorio de inicio con un disco en vivo),
Drake Clarris
fuente
2
Está combinando discos duros y sistemas de archivos en su primer punto. Si monta / dev / sdb1 en algún punto del sistema de archivos, puede acceder a los archivos en la unidad. Si abre / dev / sdb1 directamente, verá los bloques de disco sin formato. Generalmente no es muy útil, especialmente si utiliza sistemas de archivos cifrados.
doneal24
Estaba tratando de relacionarlo de una manera que los usuarios de Windows pudieran entender. C: tampoco es un disco duro en Windows, pero todo el mundo lo llama así
Drake Clarris
1.Puedes conservar tus archivos sin letras. 2.En los sistemas POSIX, un disco duro se puede particionar como un todo sin una tabla de particiones, y una unidad de disco USB puede tener una tabla de particiones. nombre.
Behrooz
0

Si mira hacia atrás en el historial, también puede ver que Unix comenzó en el momento de los sistemas de cintas de 8 pistas para audio y los sistemas de datos de IBM de 9 pistas (8 pistas / 8 bits para datos, uno para paridad). Técnicamente muy similar.

En ese momento, la información sobre la ubicación de los archivos se almacenaba en partes de la información en cinta y se definía hacia adelante y hacia atrás cuando se leían datos de la cinta (como un archivo, con posición inicial y firma final); también le explica por qué no tenía solo una FAT al comienzo de la unidad, sino que tenía varias para acelerar la búsqueda. Y si tenía varias unidades, estaban vinculadas dentro de / dev y a través de la dirección del archivo que movía entre los dispositivos.

Creo que podría tener la opinión de que comenzó simplemente antes y que la decisión detrás del área MS Dos (CP / M) y más tarde Windows NT simplemente está relacionada con las letras de unidad de mainframe VM en lugar de un solo punto de entrada porque en ese momento parecía más moderno, las cantidades de datos de hoy no existían y no pensaron que eventualmente terminaría sin tener suficientes letras de unidad o que estaría demasiado desordenado.

9-Track-Drive y asignación de letra de unidad

Peter
fuente