Por que o sistema de arquivos do Linux foi projetado como uma única árvore de diretórios?

91

Alguém pode explicar por que o Linux foi projetado como uma única árvore de diretórios?

Enquanto no Windows podemos ter várias unidades como C:\, e D:\, há uma única raiz no Unix. Algum motivo específico aí?

user2720323
fonte
14
@terdon - Eu acho que ele está perguntando sobre ter um único diretório raiz (/) vs. estilo DOS (C: \ D: \).
Jordanm #
27
Você pode (e geralmente possui) várias unidades no Linux também. De fato, o princípio básico é o mesmo C:e também D:são pontos de montagem no Windows. O equivalente do Windows /é que My Computertudo está montado sob isso.
terdon
61
Eu acho que uma pergunta mais relevante seria "por que um sistema operacional NÃO teria uma única raiz"? (A resposta para DOS / Windows seria erro de projeto / incapacidade de planejar para o futuro suposição / desnecessário)
JoelFan
21
O Windows escolheu esse sistema bizarro por causa do MS-DOS antes dele e o MS-DOS seguiu o precedente estabelecido pelo CP / M. O MS-DOS era um sistema baseado em unidade de disquete (A: e B: inicialmente, às vezes, por exemplo, em um único sistema de unidade, A: e B: eram a mesma unidade, mas dois discos lógicos diferentes para fins de operação de troca / cópia) . Como a maioria das pessoas danificadas pelos PCs do MS-DOS, o OP pensa que /no Linux é o mesmo que C: no MSDOS / Windows, quando na verdade não é a mesma coisa.
Warren P
25
Na verdade, C:, D:e outras coisas é apenas a compatibilidade com DOS e Win32; O Windows NT internamente possui uma hierarquia de objetos parecida com o UNIX, onde as letras das unidades (e em geral as coisas do Win32) são apenas links simbólicos para os objetos "reais" ( c:\file.txtna verdade \??\c:\file.txt, por \??\c:ser um link simbólico para, por exemplo \device\harddisk0\partition1). Veja, por exemplo, aqui
Matteo Italia

Respostas:

192

Como o sistema de arquivos Unix é anterior ao Windows há muitos anos, pode-se reformular a pergunta para "por que o Windows usa um designador separado para cada dispositivo?".

Um sistema de arquivos hierárquico tem a vantagem de encontrar qualquer arquivo ou diretório como filho do diretório raiz. Se você precisar mover dados para um novo dispositivo ou dispositivo de rede, o local no sistema de arquivos poderá permanecer o mesmo e o aplicativo não verá a diferença.

Suponha que você tenha um sistema em que o sistema operacional seja estático e que exista um aplicativo que tenha altos requisitos de E / S. Você pode montar / usr somente leitura e colocar / opt (se o aplicativo estiver lá) nas unidades SSD. A hierarquia do sistema de arquivos não muda. No Windows, isso é muito mais difícil, principalmente em aplicativos que insistem em viver em C: \ Arquivos de Programas \

doneal24
fonte
27
E essa pergunta (retórica) tem uma resposta: tradição. Apenas uma tradição diferente da que o Unix veio. O Windows obtém isso do DOS, do CP / M-80, que seguia um padrão comum de muitos sistemas operacionais de minicomputadores e mainframe. Os nomes das unidades foram reduzidos de DISK0:ou SY:para A:.
RBerteig
6
@RBerteig - talvez tradição, especialmente no caso Windows, mas Rob Pike apresenta um argumento bastante convincente para esquemas de nomeação no estilo Unix em The Hideous Name, pdos.csail.mit.edu/~rsc/pike85hideous.pdf
Bruce Ediger,
13
Desde o Windows NT, acredito, foi possível montar um dispositivo em um determinado caminho virtual no Windows para realizar exatamente a mesma coisa que o Unix, embora seja incomum em PCs domésticos (um pouco mais comuns em servidores e implantações de negócios). Você pode optar por ver isso como uma justificativa do Caminho Unix (tm), se desejar.
JSB #
8
@ BruceEdiger Não vou tentar argumentar que o DOS estava certo. Apenas salientando que há um contexto para o Windows ser do jeito que está e que não foi apenas algo que a MS tirou do chapéu.
RBerteig 7/10
1
@BruceEdiger: Uau. Bom papel. É também uma das poucas vezes que vi Pike estar inquestionavelmente errado sobre alguma coisa. (Nomeadamente, o sistema de exibição de nomes da ARPANET não pode ser escalonado. Atualmente, nós o chamamos de DNS e ele foi escalado muito bem. Os conceitos principais de um espaço hierárquico absoluto com autoridade e delegação permanecem completamente inalterados). É certo que isso ocorre porque as redes não IP relevantes para o correio desapareceram.
Kevin Cathcart
87

Isso ocorre em parte por razões históricas e em parte porque faz mais sentido dessa maneira.

Multics

Multics foi o primeiro sistema operacional a introduzir o sistema de arquivos hierárquico como o conhecemos hoje, com diretórios que podem conter diretórios. Citando "Um sistema de arquivos de uso geral para armazenamento secundário" por RC Daley e PG Neumann:

A seção 2 do artigo apresenta a estrutura hierárquica dos arquivos, o que permite o uso flexível do sistema. Essa estrutura contém recursos suficientes para garantir versatilidade. (…)

Para facilitar o entendimento, a estrutura do arquivo pode ser pensada como uma árvore de arquivos, alguns dos quais são diretórios. Ou seja, com uma exceção, cada arquivo (por exemplo, cada diretório) encontra-se diretamente apontado por exatamente uma ramificação em exatamente um diretório. A exceção é o diretório raiz, ou raiz, na raiz da árvore. Embora não seja explicitamente apontado em nenhum diretório, a raiz é apontada implicitamente por um ramo fictício conhecido pelo sistema de arquivos. (…)

A qualquer momento, considera-se que um usuário está operando em algum diretório, chamado diretório de trabalho. Ele pode acessar um arquivo efetivamente apontado por uma entrada em seu diretório de trabalho simplesmente especificando o nome da entrada. Mais de um usuário pode ter o mesmo diretório de trabalho ao mesmo tempo.

Como em muitos outros aspectos, o Multics buscava flexibilidade. Os usuários podem trabalhar em uma subárvore do sistema de arquivos e ignorar o restante, e ainda se beneficiar dos diretórios para organizar seus arquivos. Diretórios também foram usados ​​para controle de acesso - o atributo READ permitiu que os usuários listassem os arquivos em um diretório, e o atributo EXECUTE permitiu que os usuários acessassem arquivos nesse diretório (isso, como muitos outros recursos, residia no unix).

Multics também seguiu o princípio de ter um único pool de armazenamento. O artigo não aborda esse aspecto. Um único pool de armazenamento combinava bem com o hardware da época: não havia dispositivos de armazenamento removíveis, pelo menos nenhum que os usuários se importassem. O Multics tinha um pool de armazenamento de backup separado, mas isso era transparente para os usuários.

Unix

O Unix se inspirou bastante no Multics, mas buscou a simplicidade, enquanto o Multics buscou a flexibilidade.

Um único sistema de arquivos hierárquico era adequado ao Unix. Como no Multics, os pools de armazenamento geralmente não eram relevantes para os usuários. No entanto, havia dispositivos removíveis e o Unix os expôs aos usuários, através dos comandos mounte umount(reservados ao "superusuário", ou seja, o administrador). Em "O sistema de compartilhamento de tempo UNIX" , Dennis Ritchie e Ken Thompson explicam:

Embora a raiz do sistema de arquivos esteja sempre armazenada no mesmo dispositivo, não é necessário que toda a hierarquia do sistema de arquivos resida nesse dispositivo. Há uma solicitação de sistema de montagem com dois argumentos: o nome de um arquivo comum existente e o nome de um arquivo especial cujo volume de armazenamento associado (por exemplo, um pacote de disco) deve ter a estrutura de um sistema de arquivos independente contendo sua própria hierarquia de diretórios . O efeito da montagem é fazer com que as referências ao arquivo comum até agora se refiram ao diretório raiz do sistema de arquivos no volume removível. Com efeito, mount substitui uma folha da árvore da hierarquia (o arquivo comum) por uma nova subárvore inteira (a hierarquia armazenada no volume removível). Após a montagem, praticamente não há distinção entre os arquivos no volume removível e os do sistema de arquivos permanente. Em nossa instalação, por exemplo, o diretório raiz reside em uma pequena partição de uma de nossas unidades de disco, enquanto a outra unidade, que contém os arquivos do usuário, é montada pela sequência de inicialização do sistema. Um sistema de arquivos montável é gerado gravando em seu arquivo especial correspondente. Um programa utilitário está disponível para criar um sistema de arquivos vazio ou pode-se simplesmente copiar um sistema de arquivos existente.

O sistema de arquivos hierárquico também tem a vantagem de concentrar a complexidade do gerenciamento de vários dispositivos de armazenamento no kernel. Isso significava que o kernel era mais complexo, mas todos os aplicativos eram mais simples como resultado. Como o kernel precisa se preocupar com dispositivos de hardware, mas a maioria dos aplicativos não, esse é um design mais natural.

janelas

O Windows rastreia sua linhagem até duas linhagens: o VMS , um sistema operacional originalmente projetado para o minicomputador VAX , e o CP / M , um sistema operacional projetado para os primeiros microcomputadores Intel.

O VMS tinha um sistema de arquivos hierárquico distribuído, Arquivos-11 . No Arquivo-11, o caminho completo para um arquivo contém um nome de nó, uma designação de conta nesse nó, um nome de dispositivo, um caminho de árvore de diretório, um nome de arquivo, um tipo de arquivo e um número de versão. O VMS tinha um poderoso recurso de nome lógico , permitindo que os atalhos fossem definidos para diretórios específicos; portanto, os usuários raramente precisavam se preocupar com o local "real" de um diretório.

O CP / M foi projetado para computadores com 64kB de RAM e uma unidade de disquete, por isso foi simplificado. Não havia diretórios, mas uma referência de arquivo poderia incluir uma indicação de unidade ( A:ou B:).

Quando o MS-DOS 2.0 introduziu diretórios, o fez com uma sintaxe compatível com o MS-DOS 1, que seguia o CP / M. Portanto, os caminhos estavam enraizados em uma unidade com um nome de uma letra. (Além disso, o caractere de barra /foi usado no VMS e no CP / M para iniciar as opções de linha de comando; portanto, um caractere diferente teve que ser usado como um separador de diretório. É por isso que o DOS e o Windows posterior usam barra invertida, embora alguns componentes internos também suportem barra )

O Windows manteve a compatibilidade com o DOS e a abordagem VMS, mantendo a noção de letras de unidade, mesmo quando elas se tornaram menos relevantes. Hoje, sob o capô, o Windows usa caminhos UNC ( originalmente desenvolvidos pela Microsoft e IBM para OS / 2 , de ascendência relacionada). Embora isso seja reservado para usuários avançados (provavelmente devido ao peso do histórico), o Windows permite a montagem através de pontos de nova análise .

Gilles
fonte
3
Embora não seja o comportamento padrão, nos sistemas de arquivos NTFS, o Windows também pode montar todo o seu armazenamento em uma única raiz: technet.microsoft.com/en-us/library/cc753321.aspx howtogeek.com/98195/… serverfault.com/questions / 24400 /…
gerlos 08/10
3
Parece que a parte relevante é que o MS-DOS 1.0 foi baseado em disquete. Nesse sistema, (a) era importante saber em qual disco físico seus arquivos estavam e (b) A:e B:era uma convenção decente para distinguir entre suas unidades de disquete, se você tivesse duas delas. Quando o suporte ao disco rígido foi adicionado no MS-DOS 2.0, a C:designação da unidade permitiu compatibilidade com versões anteriores, tratando o HD como um disquete BIG.
user1024
5
Na verdade, inicialmente o CP / M foi projetado para ser executado em 16 , não em 64 KB de RAM. A figura de 64 KB provavelmente deve permitir às aplicações um pouco de espaço para respirar; enquanto o processador de comando (CCP) foi substituído e recarregado, se necessário, o BIOS e o BDOS residiam na memória o tempo todo. Sim, é daí que vem o BIOS - a IBM não apresentou o termo! Consulte Wikipedia CP / M: modelo de hardware e componentes do sistema operacional . Lembre-se de que 16 KB é apenas cerca de três páginas densamente escritas (70 linhas × 80 caracteres / linha × 3 páginas = 16800 bytes).
um CVn 09/10
36

Não há preocupações de segurança por trás de uma única árvore de diretórios.

Os caras que criaram o Unix tinham muita experiência com sistemas operacionais que exigiam que os usuários soubessem qual dispositivo físico continha um determinado recurso. Como parte do objetivo de um sistema operacional é criar uma máquina abstrata sobre o hardware real, eles acharam muito mais fácil dispensar os recursos de endereçamento por sua localização física e decidiram colocar tudo em uma única árvore de nomes.

Esta é apenas uma parte do gênio por trás do design do Unix .

msw
fonte
28

Observe que os nomes das letras de unidade do MS-DOS que persistem no Windows moderno são um arenque vermelho aqui. Os nomes das letras de unidades não são a melhor representação de uma estrutura de sistema de arquivos com várias raízes. Eles são uma implementação simples desse sistema.

Um sistema de arquivos implementado adequadamente, que suporta múltiplas raízes, permitiria nomes arbitrários para os volumes, como dvdrom:/path/to/file.avi. Tal como o sistema, livrar-se-ia dos problemas risíveis da interface do usuário que assolam o Windows. Por exemplo, se você conectar um dispositivo como uma câmera, a interface do usuário do Windows Explorer fará com que você acredite que existe um dispositivo chamado Câmera (ou qualquer outra) e que você possui um caminho semelhante Computer\Camera\DCIM\.... No entanto, se você recortar e colar a versão textual desse caminho no Explorer, ele não funcionará porque alguns componentes do nome do caminho são uma ficção da interface do usuário, desconhecida pelo sistema operacional subjacente. Em um sistema adequadamente implementado, com múltiplas raízes, seria bom: haveria umacamera:\DCIM\...caminho que é reconhecido uniformemente em todos os níveis do sistema. Além disso, se você portasse um disco rígido antigo a partir de um PC ANTIGO, não ficaria preso a um nome de letra de unidade como F:, mas seria capaz de nomeá-lo como quiser old-disk:.

Portanto, se o Unix tivesse várias raízes na estrutura do sistema de arquivos, isso seria feito da seguinte maneira: não no MS-DOS e no Windows com nomes de unidades de uma letra. Em outras palavras, vamos comparar apenas o esquema Unix com um bom design multi-raiz.

Então, por que o Unix não tem uma implementação sã de múltiplas raízes, em favor da implementação sã de uma raiz? Provavelmente é apenas por simplicidade. Os pontos de montagem fornecem toda a funcionalidade de poder acessar volumes por nomes. Não há necessidade de estender o espaço para nome com uma sintaxe de prefixo adicional.

Matematicamente falando, qualquer gráfico de árvore separado ("floresta") pode ser associado adicionando um nó raiz e transformando as partes separadas em filhos.

Além disso, é mais flexível que os volumes não precisem estar no nível raiz. Como não há sintaxe especial que denota volume (é apenas um componente do caminho), os pontos de montagem podem estar em qualquer lugar. Se você levar em três discos antigos para sua máquina, você pode tê-los como /old-disk/one, /old-disk/two, etc. Você pode organizar discos como quiser, a maneira como você organiza os arquivos e diretórios.

Podem ser gravados aplicativos que dependem de caminhos, e a validade dos caminhos pode ser mantida quando os dispositivos de armazenamento são reconfigurados. Por exemplo, os aplicativos podem usar caminhos conhecidos como /var/loge /var/lib. Depende de você estar /var/loge /var/libestar no mesmo volume de disco ou em volumes separados. Você pode migrar um sistema para uma nova topologia de armazenamento, preservando os caminhos.

Os pontos de montagem são uma boa ideia, e é por isso que o Windows os possui desde o Windows 2000.

Os pontos de montagem de volume são robustos contra as alterações do sistema que ocorrem quando os dispositivos são adicionados ou removidos de um computador. Microsoft Technet

Kaz
fonte
6
Talvez por coincidência, seu "bom design multi-raiz" se pareça muito com o antigo sistema AmigaDOS , que permitia nomes de volumes arbitrários, incluindo volumes "atribuídos" que se referiam a um diretório específico dentro de outro volume. Você pode até (com o software apropriado ) ter volumes "virtuais" como, por exemplo, um FTP:volume que permita acessar arquivos em qualquer servidor FTP com um caminho semelhante FTP:hostname/path/to/file.
Ilmari Karonen
3
Esta realmente não é uma boa resposta, pois parece ser extremamente subjetiva. É bastante abertamente Windows batendo.
Rig
3
@Rig Embora isso possa ser verdade, o Windows merece uma resposta completa por ainda ter esses nomes de letras de unidade, que remontam ao MS-DOS. Este é o sistema de arquivos com várias raízes que a maioria dos usuários está familiarizada, mas não podemos realmente usá-lo para fins de comparação com a raiz única, porque é um exemplo simples desse sistema.
Kaz
3
@ Kaz Ainda acho essa resposta mais desmedida. O Windows diferencia o sistema de arquivos, mas não o torna errado, horrível ou um crime contra a humanidade. Você não gosta como tem direito. A Microsoft nem inventou esse esquema, eles o emprestaram de um sistema popular da época, mas precisam mantê-lo para uma manutenção razoável com o código legado.
Rig
1
@Rig Sure; não é mais horrível do que, por exemplo, obter o seu próximo jantar por meio de uma ponta de flint. As pontas das flechas de sílex eram realmente o estado da arte em seu auge . Ah, mas opa, na verdade não podemos dizer isso sobre o DOS e as letras de unidade, podemos ... tanto por analogias.
Kaz
13

* Nix e Windows montam suas unidades. No Windows, eles são montados automaticamente em pontos de montagem que, por padrão, estão em ordem alfabética crescente. Esses padrões são:

  • A:e B:=> disquetes
  • C: => primeira partição do primeiro disco rígido
  • D: => próxima partição ou próximo disco rígido ou unidade de CD / DVD, se nenhuma outra partição estiver presente.

Cada um desses pontos de montagem é um diretório.

No * nix, os pontos de montagem são decididos pelo usuário. Por exemplo, eu tenho uma partição montada como /e outra como /home. Portanto, /homeé uma unidade separada, seria o equivalente a dizer E:no Windows.

Nos dois casos, Windows e * nix, os pontos de montagem são diretórios separados. A única diferença é que, no * nix, esses diretórios separados são subdiretórios de /, C:enquanto no Windows, todos os pontos de montagem são montados diretamente sob o /, My Computerdigamos.

Do ponto de vista do usuário, a principal vantagem é que as montagens são completamente transparentes. Não preciso saber que o diretório /homeestá realmente em uma partição separada. Eu posso apenas usá-lo como um diretório normal. Em vez disso, no DOS, eu teria que chamá-lo explicitamente pelo nome do ponto de montagem, digamosE:\home

As unidades externas são montadas da mesma maneira nos dois sistemas. Diga D:para Windows e /mnt/cdromLinux. Cada um deles é um diretório, eu realmente não vejo a diferença. Quando você coloca um CD-ROM em sua unidade no Windows, o disco é montado D:exatamente como no Linux.

terdon
fonte
3
Por curiosidade, você sabe o que aconteceria se alguém quisesse criar 27 unidades no Windows? Como o Windows chamaria a 27ª unidade? : D
Joseph R.
2
Hahaha Parece que o Windows é muito chato para fazer isso.
Joseph R.
3
Nitpick menor: as letras de unidade no Windows são padronizadas em ordem alfabética crescente, mas podem ser e frequentemente são renomeadas.
RBerteig 7/10
3
@terdon: ele montaria a unidade dentro de um diretório - exatamente como você faz nos sistemas operacionais POSIX.
Matteo Italia
3
@ JosephphR: Em algum momento, não tenho certeza de quando, mas provavelmente o NT, o Windows ganhou a capacidade de montar unidades em diretórios, como o Unix. Por padrão, ninguém realmente faz isso (o que me surpreende: com a frequência das reinstalações de nuke e pavimentar, eu pensaria que algo análogo a colocar / home em um volume separado já teria se tornado popular agora). No entanto, se as letras / números / símbolos das unidades não forem executadas, é isso que você precisará fazer se desejar adicionar mais unidades ao sistema.
The Spooniest
10

Concordo com as respostas acima, especialmente a resposta de Doug O'Neal, mas acho que todas elas perdem um pouco, assim como os pontos de montagem explícitos do dispositivo, como o MS-DOS "C:" ou "A:".

Rob Pike escreveu The Hideous Name sobre sintaxe de nomes, mas Russ Cox resumiu :

Os espaços para nome ... são mais poderosos quando novas semânticas podem ser adicionadas sem adicionar nova sintaxe.

Um único espaço de nome onde os dispositivos podem ser montados arbitrariamente permite operações realmente flexíveis. Uso regularmente /mnt/sdb1e /mnt/cdromcoloco temporariamente um disco ou CD atualmente não utilizado no sistema geral de arquivos. Não é incomum ter diretórios pessoais em um servidor NFS; portanto, independentemente da máquina em que você efetua login, você obtém o mesmo em $HOMEtodos os lugares.

Tudo se resume a isso: ter uma sintaxe especial para coisas especiais impõe limites definidos ao que você pode fazer. Se você pode montar apenas um disco ou CD ou DVD não utilizado, ou um sistema de arquivos de rede / "compartilhar" em "E:" ou "W:" ou qualquer outra coisa, você tem muito menos flexibilidade.

Bruce Ediger
fonte
1
Você realmente não precisa de links simbólicos para isso. Você pode montar diretamente uma partição (ou armazenamento em rede ou qualquer outra coisa) em qualquer caminho, como / usr / local - embora sempre me confunda quando encontro uma rede em que / usr / local aponta para uma montagem em rede. Sim, eles existem e há algum motivo para fazê-lo: / usr / local é um dos locais padrão para o seu administrador colocar coisas que não são do distribuidor do SO.
9788 Christopher Creutzig #
@ Christopher Creutzig - um link simbólico acordado não é necessário para o meu exemplo, eu só queria dar outro exemplo de como um esquema de nomeação flexível pode funcionar para você. Talvez não seja o melhor exemplo.
precisa
Olhe para a web estúpida, a propósito. proto://specifichost.domain.tld/topleveldir/middle/specificdoc.html.
Kaz
2
@Christopher Creutzig - Eu configurei / usr / local como uma unidade de rede em alguns lugares. "local" significa local no site, não na máquina.
doneal24
3
@ Kaz, acho que o proto://negócio é uma necessidade pragmática. Não se espera que todo software saiba sobre todos os esquemas de URI existentes. Portanto, pode ser útil saber quando o ID do esquema termina e o restante do URI é iniciado.
Adrian Ratnapala
5

Isso é bobo. O Windows também possui um único ponto de hierarquia. Mas é oculto e não é padrão. Como a maioria das coisas, janelas.

Nesse caso, é o conceito "Meu computador". Isso é equivalente à raiz (/) no Unix. Lembre-se de que raiz é um conceito que existe no kernel. voce gosta ou nao. Assim como o Windows trata o "Meu Computador". é claro, você pode montar uma partição no root no unix, e é isso que a maioria das pessoas faz. E muitas coisas procurarão um caminho específico para as coisas (por exemplo, / etc /), mas você não está limitado por ela. Por todos os meios, monte suas unidades em / C: /. você não está proibido de fazer isso no unix.

C: \ não é uma raiz no Windows, é o ponto de montagem de uma partição. Que DEVE estar no nível superior "Meu Computador". Enquanto no unix, você pode montar uma partição sob qualquer outra árvore. Portanto, no linux, você pode ter o C: montado /enquanto você tem o D: montado /mnt/d/... ou até mesmo montado, /mas isso é complicado e depende de como os dois sistemas de arquivos se comportam ao montar no topo de um caminho já montado.

Assim, você pode obter exatamente o mesmo que o Windows, forçando-se a seguir as mesmas limitações que o Windows impõe aleatoriamente.

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

Então você teria que passar nas opções de montagem nas opções de inicialização. já que você não terá um / etc / ..., mas também simulará as limitações que o Windows impõe, como é o que faz.

gcb
fonte
4
O Windows tem uma única hierarquia sob o capô e possui pontos de montagem, mas não os usa por padrão.
Gilles
1
@ Gilles não sei se entendi. Como anexar todos os drivers ao nó raiz "Meu Computador" não o usa por padrão?
Gcb # 8/13
5
Essa é apenas a apresentação da GUI. Caminhos de arquivo não usam My Computer.
Gilles
3
My Computeré o nó raiz da hierarquia do Shell. ele contém unidades, se tiverem uma letra de unidade , mas também o painel de controle e qualquer Windows Phone conectado. A hierarquia do Shell usa PIDLs em vez de caminhos.
MSalters
4
@gcb: o ponto é que a hierarquia do shell não é diretamente utilizável em aplicativos "normais". Você não pode chamar CreateFile"Meu Computador" ou outras pastas shell; é uma abstração entendida apenas pelo código relacionado ao shell, todas as chamadas do kernel (e, portanto, 90% dos aplicativos, já que o gerenciamento de arquivos na maioria dos idiomas é implementado em termos de APIs de arquivos do kernel) não sabem nada sobre isso. As pastas do shell são utilizáveis ​​somente quando os programas usam as "caixas de diálogo padrão" (que compreendem o espaço de nomes do shell) e somente quando os arquivos selecionados são mapeados diretamente para um caminho "real" (= compreendido pelo kernel).
Matteo Italia
5

O motivo do Windows ter letras de unidade provavelmente remonta mais ao Microsoft e DOS. A atribuição de letras a unidades removíveis era comum nos sistemas IBM; portanto, a Microsoft pode estar apenas seguindo as instruções da IBM, copiando o CP / M. E, inicialmente, o DOS não tinha diretórios de qualquer maneira.

Quando o MS-DOS era executado em computadores com um ou dois discos removíveis e sem mídia fixa, você realmente não precisava de um sistema de arquivos com diretórios. Com um, ou talvez dois discos de 180 kilobytes, você nunca teve arquivos suficientes para ter muitos problemas para organizá-los.

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

david25272
fonte
1
Isso é impreciso, na melhor das hipóteses. O CP / M antecedeu qualquer DOS Microsoft / IBM-PC por vários anos (acredito que a idéia original da IBM era usar o CP / M para seu "PC", pois era um padrão industrial de fato bastante estabelecido na época, apesar de o fato de que vários sistemas CP / M podem ser incompatíveis), e dificilmente se discute que o IBM-PC DOS foi fortemente baseado no 86-DOS, que por sua vez era basicamente um clone do CP / M compatível com código-fonte .
um CVn 09/10
4

Na verdade, o Linux é baseado no Unix (ou é o Unix, veja a discussão ) e o Unix vem do ambiente de mainframe, onde o uso de vários dispositivos era bastante óbvio. A montagem de dispositivos em uma única árvore de diretórios oferece flexibilidade máxima e não limita o número de dispositivos que o sistema operacional pode acessar.

Por outro lado, as letras DOS para unidades são um bom design para um PC com 1 ou 2 estações de disquete e unidade de disco único. O disquete grande 5,25 'é sempre A :, o pequeno 3,5' é sempre B: e a unidade de disco é sempre C :. Você sempre sabe se copiar um arquivo no disquete ou em algum lugar do disco. Você não precisa de flexibilidade se não puder conectar fisicamente mais de 2 unidades de disquete e 2 (ou 4) discos rígidos.

O design do DOS era mais amigável ao usuário final, enquanto o design do Unix era amigável ao administrador. Agora as letras das unidades são um fardo para o Windows, os usuários confiam mais em abrir automaticamente a janela do explorer com o conteúdo removível da unidade do que conhecer sua letra ... O Ubuntu faz o mesmo, na verdade.

Marinheiro Danubiano
fonte
1

Isso não é verdade, na verdade. O Windows usa outro esquema de caminhos (bem, não é o mesmo)

"Letras de unidade" são apenas algo para lembrar facilmente caminhos, discos e partições.

Os caminhos do ARC definem o caminho de um arquivo no Windows (mas são visíveis ao usuário apenas na inicialização):

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

No Windows NT, não há relação entre discos, partições e letras de unidade: você pode "colocar" um volume inteiro em uma pasta (por exemplo: c: \ myseconddisk pode ser um disco físico inteiro!)

AndreaCi
fonte
1
Os caminhos ARC são apenas para inicialização, para compatibilidade com algumas ROM quando o NT foi portado para Alpha e MIPS. Quando o sistema está em execução, ele usa caminhos UNC.
Ninjalj 08/10
0

Duas coisas que eu gostaria de destacar -

  1. Os discos rígidos no linux são de certa forma atribuídos a letras / nomes, como / dev / sdb1. Mas eles podem ser montados em qualquer lugar a partir da estrutura única / raiz
  2. A razão mais comum pela qual as pessoas (inclusive eu no passado) tinham unidades separadas no Windows era ter um lugar para guardar documentos, músicas, programas etc., de modo que, quando o Windows inevitavelmente precisasse ser reinstalado ou substituído, fosse uma atualização ou vírus ou falha no sistema de arquivos, ainda havia acesso a esses arquivos. Eu não tenho esse problema no linux - o sistema de arquivos é muito mais confiável, o sistema operacional não quebra, a menos que por alguma ação direta ou erro da minha parte (ooh! Um repositório de ponta, vamos tentar isso!), E atualizações são muito mais simples. E, no caso raro, tive que reinstalar, já que todo o software estava disponível através de repositórios ou ppas que eu adicionei (e eu poderia copiar facilmente meu diretório pessoal com um disco ativo),
Drake Clarris
fonte
2
Você está combinando discos rígidos e sistemas de arquivos no seu primeiro ponto. Se você montar / dev / sdb1 em algum momento do sistema de arquivos, poderá acessar os arquivos na unidade. Se você abrir o / dev / sdb1 diretamente, poderá ver os blocos de disco bruto. Geralmente não é muito útil, especialmente se você usar sistemas de arquivos criptografados.
doneal24
Eu estava tentando relacioná-lo de uma maneira que os usuários do Windows pudessem entender. C: não é um disco rígido no Windows também, mas todo mundo se refere a ele como que
Drake Clarris
1.Você ainda pode manter seus arquivos sem letras. 2.Em sistemas POSIX, um disco rígido pode ser particionado como um todo sem uma tabela de partição e um pen drive pode ter uma tabela de partição. nome.
Behrooz 10/10
0

Se você olhar para trás no histórico, também poderá ver que o Unix foi iniciado no momento de 8 sistemas de fita de faixa para áudio e 9 sistemas de dados IBM de faixa (8 faixas / 8 bits para dados, um por paridade). Tecnicamente muito parecido.

Naquele momento, as informações sobre a localização dos arquivos eram armazenadas em partes das informações na fita e definidas para frente e para trás quando você lê dados da fita (como um arquivo, com posição inicial e assinatura final); também explica por que você não tinha apenas um FAT no início da unidade - tinha vários para acelerar a pesquisa. E se você tiver várias unidades, elas serão vinculadas dentro de / dev e pelo endereço do arquivo que você moveu entre os dispositivos.

Acredito que você possa ter a ideia de que ele começou simplesmente mais cedo e que a decisão por trás da área MS Dos (CP / M) e posterior do Windows NT está simplesmente relacionada às letras de unidade de mainframe da VM em vez de um único ponto de entrada, porque na época parecia mais moderno, a quantidade de dados de hoje não existia e eles não pensavam que você acabaria por não ter letras de unidade suficientes ou que isso seria muito confuso.

Atribuição de 9 faixas e letra de unidade

Peter
fonte