"Tudo é um arquivo" é um pouco simplista. "Tudo aparece em algum lugar do sistema de arquivos " está mais próximo da marca e, mesmo assim, é mais um ideal do que uma lei do design de sistemas.
Por exemplo, soquetes de domínio Unix não são arquivos, mas eles aparecem no sistema de arquivos. Você pode ls -lusar um soquete de domínio para exibir seus atributos, catdados de / para um, modificar seu controle de acesso via chmod, etc.
Porém, mesmo que soquetes de rede TCP / IP regulares sejam criados e manipulados com as mesmas chamadas de sistema de soquetes BSD que os soquetes de domínio Unix, os soquetes TCP / IP não aparecem no sistema de arquivos, ¹ mesmo que não haja uma razão especialmente boa para isso. seja verdadeiro.
Outro exemplo de objetos que não são arquivos que aparecem no sistema de arquivos é o /procsistema de arquivos do Linux . Esse recurso expõe uma grande quantidade de detalhes sobre a operação em tempo de execução do kernel ao espaço do usuário , principalmente como arquivos virtuais de texto sem formatação. Muitas /procentradas são somente leitura, mas muitas /proctambém são graváveis, para que você possa alterar a maneira como o sistema é executado usando qualquer programa que possa modificar um arquivo. Infelizmente, aqui novamente temos uma não-identidade: os Unixes do tipo BSD geralmente são executados sem/proc , e os Unixes do System V expõem muito menos via do /procque o Linux.
Não posso contrastar isso com o MS Windows
Primeiro, grande parte do sentimento que você pode encontrar on-line e nos livros sobre o Unix ter tudo a ver com E / S de arquivos e o Windows estar "quebrado" nesse aspecto é obsoleto. O Windows NT corrigiu muito disso.
As versões modernas do Windows têm um sistema de E / S unificado, assim como o Unix, para que você possa ler dados de rede de um soquete TCP / IP por ReadFile()meio da API específica do Windows Sockets WSARecv(), se desejar. Isso é exatamente paralelo à maneira Unix , onde você pode ler de um soquete de rede com a read(2)chamada genérica do sistema Unix ou a chamada específica de recv(2)soquete.²
No entanto, o Windows ainda falha em levar esse conceito ao mesmo nível do Unix, mesmo aqui em 2018. Existem muitas áreas da arquitetura do Windows que não podem ser acessadas através do sistema de arquivos ou que não podem ser vistas como arquivos. Alguns exemplos:
Drivers.
O subsistema de drivers do Windows é facilmente tão rico e poderoso quanto o do Unix, mas para escrever programas para manipular drivers, você geralmente precisa usar o Windows Driver Kit , o que significa escrever código C ou .NET.
Nos sistemas operacionais tipo Unix, você pode fazer muito com os drivers na linha de comando. Você certamente já fez isso, mesmo redirecionando a saída indesejada para /dev/null.³
Comunicação entre programas.
Os programas do Windows não se comunicam facilmente entre si.
Os programas de linha de comando Unix se comunicam facilmente através de fluxos de texto e pipes. Os programas da GUI geralmente são criados sobre os programas de linha de comando ou exportam uma interface de comando de texto, para que os mesmos mecanismos simples de comunicação baseados em texto funcionem também com os programas da GUI.
O registro.
O Unix não tem equivalente direto do registro do Windows. As mesmas informações estão espalhadas pelo sistema de arquivos, a maioria delas em /etc, /proce /sys.
Se você não vê que drivers, tubulações e a resposta do Unix ao registro do Windows têm algo a ver com "tudo é um arquivo", continue lendo.
Como a filosofia "Tudo é um arquivo" faz diferença aqui?
Vou explicar isso expandindo meus três pontos acima, em detalhes.
Resposta longa, parte 1: unidades versus arquivos de dispositivos
Digamos que o seu leitor de cartão CF seja exibido E:no Windows e /dev/sdcno Linux. Que diferença prática isso faz?
Não é apenas uma pequena diferença de sintaxe.
No Linux, posso dizer dd if=/dev/zero of=/dev/sdcpara sobrescrever o conteúdo de /dev/sdccom zeros.
Pense no que isso significa por um segundo. Aqui eu tenho um programa de espaço de usuário normal ( dd(1)), no qual pedi para ler dados de um dispositivo virtual ( /dev/zero) e gravar o que eles liam em um dispositivo físico real ( /dev/sdc) através do sistema de arquivos Unix unificado. ddnão sabe que está lendo e gravando em dispositivos especiais. Ele também funcionará em arquivos regulares ou em uma mistura de dispositivos e arquivos, como veremos abaixo.
Não há uma maneira fácil de zerar a E:unidade no Windows, porque o Windows faz uma distinção entre arquivos e unidades; portanto, você não pode usar os mesmos comandos para manipulá-los. O mais próximo que você pode chegar é fazer um formato de disco sem a opção Quick Format, que zera a maior parte do conteúdo da unidade, mas depois grava um novo sistema de arquivos em cima dela. E se eu não quiser um novo sistema de arquivos? E se eu realmente quiser que o disco seja preenchido com nada além de zeros?
Sejamos generosos e digamos que realmente queremos um novo sistema de arquivos E:. Para fazer isso em um programa no Windows, preciso chamar uma API de formatação especial. No Linux, você não precisa escrever um programa para acessar a funcionalidade "formatar disco" do sistema operacional. Você acabou de executar o programa de espaço do usuário apropriado para o tipo de sistema de arquivos que você deseja criar: mkfs.ext4, mkfs.xfsou o que você tem. Esses programas gravam um sistema de arquivos em qualquer arquivo ou /devnó que você passar.
Como os mkfsprogramas de tipo nos sistemas Unixy funcionam em arquivos sem fazer distinções artificiais entre dispositivos e arquivos normais, significa que posso criar um sistema de arquivos ext4 dentro de um arquivo normal na minha caixa Linux:
$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs
Isso literalmente cria uma imagem de disco de 1 MiB no diretório atual, chamada myfs. Posso montá-lo como se fosse qualquer outro sistema de arquivos externo:
$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint
Agora eu tenho uma imagem de disco ext4 com um arquivo chamado my-passwd-entryque contém a /etc/passwdentrada do meu usuário .
Se eu quiser, posso colocar essa imagem no meu cartão CF:
$ sudo dd if=myfs of=/dev/sdc1
Ou então, posso agrupar essa imagem de disco, enviá-la por e-mail e deixá-la gravá-la em uma mídia de sua escolha, como um cartão de memória USB:
$ gzip myfs
$ echo "Here's the disk image I promised to send you." |
mutt -a myfs.gz -s "Password file disk image" you@example.com
Tudo isso é possível no Linux⁵ porque não há distinção artificial entre arquivos, sistemas de arquivos e dispositivos. Muitas coisas nos sistemas Unix são arquivos ou são acessadas através do sistema de arquivos para que pareçam arquivos ou, de alguma outra maneira, pareçam suficientemente com arquivos para que possam ser tratadas como tal.
O conceito de sistema de arquivos do Windows é uma miscelânea; faz distinções entre diretórios, unidades e recursos de rede. Existem três sintaxes diferentes, todas combinadas no Windows: o sistema de ..\FOO\BARcaminhos do tipo Unix , letras de unidades C:e caminhos UNC \\SERVER\PATH\FILE.TXT. Isso ocorre porque é um acréscimo de idéias do Unix, CP / M , MS-DOS e LAN Manager , em vez de um único design coerente. É por isso que existem tantos caracteres ilegais nos nomes de arquivos do Windows .
O Unix possui um sistema de arquivos unificado, com tudo acessado por um único esquema comum. Para um programa rodando em uma máquina Linux, não há diferença funcional entre /etc/passwd, /media/CF_CARD/etc/passwde /mnt/server/etc/passwd. Arquivos locais, mídia externa e compartilhamentos de rede são tratados da mesma maneira.⁶
O Windows pode atingir fins semelhantes ao meu exemplo de imagem de disco acima, mas você precisa usar programas especiais escritos por programadores pouco talentosos. É por isso que existem tantos programas do tipo "DVD virtual" no Windows . A falta de um recurso básico do sistema operacional criou um mercado artificial para os programas preencherem essa lacuna, o que significa que há muitas pessoas competindo para criar o melhor programa do tipo DVD virtual. Não precisamos desses programas em sistemas * ix, porque podemos apenas montar uma imagem de disco ISO usando um dispositivo de loop .
O mesmo vale para outras ferramentas, como programas de limpeza de disco , que também não precisamos nos sistemas Unix. Deseja que o conteúdo do seu cartão CF seja irremediavelmente embaralhado em vez de apenas zerado? Ok, use /dev/randomcomo fonte de dados em vez de /dev/zero:
$ sudo dd if=/dev/random of=/dev/sdc
No Linux, não reinventamos essas rodas, porque os principais recursos do sistema operacional não apenas funcionam bem o suficiente, eles funcionam tão bem que são usados de maneira generalizada. Um esquema típico para inicializar uma caixa Linux envolve uma imagem de disco virtual, por apenas um exemplo, criada usando as técnicas mostradas acima.⁷
Eu sinto que é justo salientar que se Unix tinha integrado TCP / IP I / O para o sistema de arquivos desde o início, não teríamos o netcatvs socatvs Ncatvs bagunça , cuja causa foi a mesma fraqueza de design que levam à proliferação de ferramentas de imagem de disco e limpeza no Windows: falta de um sistema operacional aceitável.nc
Resposta longa, parte 2: Canais como arquivos virtuais
Apesar de ter raízes no DOS, o Windows nunca teve uma rica tradição de linha de comando.
Isso não quer dizer que o Windows não tenha uma linha de comando ou que não tenha muitos programas de linha de comando. Atualmente, o Windows tem um shell de comando muito poderoso, chamado apropriadamente de PowerShell .
No entanto, existem efeitos indiretos dessa falta de tradição na linha de comando. Você obtém ferramentas como a DISKPARTque é quase desconhecida no mundo do Windows, porque a maioria das pessoas faz particionamento de disco e outros através do snap-in MMC do Gerenciamento do Computador. Então, quando você precisa criar um script para a criação de partições, descobre que isso DISKPARTnão foi feito para ser conduzido por outro programa. Sim, você pode gravar uma série de comandos em um arquivo de script e executá-lo via DISKPART /S scriptfile, mas é tudo ou nada. O que você realmente deseja em tal situação é algo mais parecido com o GNUparted , que aceita comandos únicos como parted /dev/sdb mklabel gpt. Isso permite que o seu script faça o tratamento de erros passo a passo.
O que tudo isso tem a ver com "tudo é um arquivo"? Fácil: os tubos transformam a E / S do programa de linha de comando em "arquivos" de uma espécie. Pipes são fluxos unidirecionais , sem acesso aleatório como um arquivo de disco comum, mas em muitos casos a diferença não tem conseqüências. O importante é que você pode anexar dois programas desenvolvidos de forma independente e fazê-los se comunicar por meio de texto simples. Nesse sentido, quaisquer dois programas projetados com o Modo Unix em mente podem se comunicar.
Nos casos em que você realmente precisa de um arquivo, é fácil transformar a saída do programa em um arquivo:
$ some-program --some --args > myfile
$ vi myfile
Mas por que gravar a saída em um arquivo temporário quando a filosofia "tudo é um arquivo" oferece uma maneira melhor? Se tudo o que você deseja fazer é ler a saída desse comando em um vibuffer do editor, vifaça isso diretamente para você. No modo vi"normal", diga:
:r !some-program --some --args
Isso insere a saída desse programa no buffer ativo do editor na posição atual do cursor. Sob o capô, viestá usando pipes para conectar a saída do programa a um pouco de código que usa as mesmas chamadas do SO que usaria para ler um arquivo. Eu não ficaria surpreso se os dois casos :r- isto é, com e sem !- ambos usassem o mesmo loop genérico de leitura de dados em todas as implementações comuns de vi. Não consigo pensar em uma boa razão para não fazê-lo.
Este também não é um recurso recente vi; tudo volta ao antigo ed(1)editor de texto.⁸
Essa idéia poderosa aparece repetidamente no Unix.
Para um segundo exemplo disso, lembre-se do meu muttcomando de email acima. O único motivo para escrever isso como dois comandos separados é que eu queria que o arquivo temporário fosse nomeado *.gz, para que o anexo do email fosse nomeado corretamente. Se não me importasse com o nome do arquivo, poderia ter usado a substituição de processo para evitar a criação do arquivo temporário:
$ echo "Here's the disk image I promised to send you." |
mutt -a <(gzip -c myfs) -s "Password file disk image" you@example.com
Isso evita o temporário, transformando a saída gzip -cem um FIFO (que é semelhante a arquivo) ou em um /dev/fdobjeto (que é semelhante a arquivo). (O Bash escolhe o método com base nos recursos do sistema, pois /dev/fdnão está disponível em todos os lugares.)
Por uma terceira maneira, essa poderosa idéia aparece no Unix, considere gdbnos sistemas Linux. Este é o depurador usado para qualquer software escrito em C e C ++. Os programadores que chegam ao Unix de outros sistemas olham gdbe quase invariavelmente reclamam: "Eca, é tão primitivo!" Em seguida, eles procuram um depurador da GUI, encontram um dos vários existentes e continuam felizes seu trabalho ... muitas vezes nunca percebendo que a GUI é executada gdbpor baixo, fornecendo um bonito shell em cima dele. Não existem depuradores de baixo nível concorrentes na maioria dos sistemas Unix porque não há necessidade de programas competirem nesse nível. Tudo o que precisamos é de uma boa ferramenta de baixo nível na qual todos possamos basear nossas ferramentas de alto nível, se essa ferramenta de baixo nível se comunicar facilmente através de tubos.
Isso significa que agora temos uma interface de depurador documentada que permitiria a substituição de entrada gdb, mas infelizmente o principal competidor gdb não seguiu o caminho de baixo atrito .
Ainda assim, é pelo menos possível que alguma gdbsubstituição futura apareça de forma transparente simplesmente clonando sua interface de linha de comando. Para fazer o mesmo em uma caixa do Windows, os criadores da ferramenta substituível teriam que definir algum tipo de plugin formal ou API de automação. Isso significa que isso não acontece, exceto pelos programas mais populares, porque é muito trabalhoso criar uma interface de usuário de linha de comando normal e uma API de programação completa.
Essa mágica acontece através da graça do IPC generalizado baseado em texto .
Embora o kernel do Windows possua pipes anônimos no estilo Unix , é raro ver programas de usuário normais usá-los para IPC fora de um shell de comando, porque o Windows não possui essa tradição de criar todos os serviços principais em uma versão de linha de comando primeiro e depois criar a GUI. topo dela separadamente. Isso leva à impossibilidade de fazer algumas coisas sem a GUI, razão pela qual existem tantos sistemas de área de trabalho remota para Windows, em comparação com o Linux: o Windows é muito difícil de usar sem a GUI.
Por outro lado, é comum administrar remotamente caixas Unix, BSD, OS X e Linux remotamente via SSH. E como isso funciona, você pergunta? O SSH conecta um soquete de rede (que é semelhante a um arquivo) a um pseudo-tty em /dev/pty*(que é semelhante a um arquivo). Agora, seu sistema remoto está conectado ao seu local através de uma conexão que combina perfeitamente com o Modo Unix, de modo que você pode canalizar dados através da conexão SSH , se necessário.
Você está tendo uma idéia de quão poderoso esse conceito é agora?
Um fluxo de texto canalizado é indistinguível de um arquivo da perspectiva de um programa, exceto que é unidirecional. Um programa lê de um canal da mesma maneira que lê de um arquivo: através de um descritor de arquivo . FDs são absolutamente essenciais para o Unix; o fato de arquivos e pipes usarem a mesma abstração para E / S em ambos deve lhe dizer uma coisa.⁹
O mundo Windows, sem essa tradição de comunicações de texto simples, convive com interfaces OOP pesadas via COM ou .NET . Se você precisar automatizar esse programa, também deverá escrever um programa COM ou .NET. Isso é um pouco mais difícil do que instalar um pipe em uma caixa Unix.
Os programas do Windows que não possuem essas APIs de programação complicadas podem se comunicar apenas através de interfaces empobrecidas, como a área de transferência ou Arquivo / Salvar, seguido de Arquivo / Abrir.
Resposta longa, parte 3: o registro x arquivos de configuração
A diferença prática entre o registro do Windows e a maneira Unix de configuração do sistema também ilustra os benefícios da filosofia "tudo é um arquivo".
Nos sistemas do tipo Unix, posso ver as informações de configuração do sistema na linha de comando apenas examinando os arquivos. Eu posso mudar o comportamento do sistema modificando esses mesmos arquivos. Na maioria das vezes, esses arquivos de configuração são apenas arquivos de texto sem formatação, o que significa que posso usar qualquer ferramenta no Unix para manipulá-los que possam funcionar com arquivos de texto sem formatação.
Criar scripts para o registro não é tão fácil no Windows.
O método mais fácil é fazer as alterações na GUI do Editor do Registro em uma máquina e, em seguida, aplicar cegamente essas alterações em outras máquinas com arquivos regeditvia*.reg . Isso não é realmente "script", pois não permite fazer nada condicionalmente: é tudo ou nada.
Se as alterações no registro precisarem de alguma lógica, a próxima opção mais fácil é aprender o PowerShell , que basicamente significa aprender a programação do sistema .NET. Seria como se o Unix tivesse apenas o Perl, e você tivesse que fazer toda a administração ad hoc do sistema através dele. Agora, sou fã de Perl, mas nem todo mundo é. O Unix permite que você use qualquer ferramenta que desejar, desde que possa manipular arquivos de texto sem formatação.
Notas de rodapé:
O plano 9 corrigiu esse passo em falso do projeto, expondo a E / S da rede por meio do /netsistema de arquivos virtual .
O Bash possui um recurso chamado/dev/tcp que permite E / S de rede através de funções regulares do sistema de arquivos. Como é um recurso do Bash, e não um recurso do kernel, não é visível fora do Bash ou em sistemas que não usam o Bash . Isso mostra, por exemplo, por que é uma boa idéia tornar todos os recursos de dados visíveis através do sistema de arquivos.
Por "Windows moderno", quero dizer o Windows NT e todos os seus descendentes diretos, que incluem o Windows 2000, todas as versões do Windows Server e todas as versões do Windows orientadas para a área de trabalho a partir do XP. Uso o termo para excluir as versões do Windows baseadas em DOS, sendo o Windows 95 e seus descendentes diretos, Windows 98 e Windows ME, além de seus predecessores de 16 bits.
Você pode ver a distinção pela falta de um sistema de E / S unificado nesses últimos SOs. Você não pode passar um soquete TCP / IP para ReadFile()no Windows 95; você só pode passar soquetes para as APIs do Windows Sockets. Consulte o artigo seminal de Andrew Schulman, Windows 95: O que não é para aprofundar este tópico.
Não se engane, /dev/nullé um verdadeiro dispositivo de kernel em sistemas do tipo Unix, não apenas um nome de arquivo com uma caixa especial, como é o equivalente superficial NULno Windows.
Embora o Windows tente impedir que você crie um NULarquivo, é possível ignorar essa proteção com meros truques , enganando a lógica de análise de nome de arquivo do Windows. Se você tentar acessar esse arquivo com cmd.exeou Explorer, o Windows se recusará a abri-lo, mas você poderá gravá-lo via Cygwin, pois ele abre arquivos usando métodos semelhantes ao programa de exemplo e pode excluí-lo por meio de truques semelhantes .
Por outro lado, o Unix permite rm /dev/null, contanto que você tenha acesso de gravação /dev, e recrie um novo arquivo em seu lugar, tudo sem truques, porque esse nó de desenvolvimento é apenas outro arquivo. Enquanto esse nó de desenvolvimento está ausente, o dispositivo nulo do kernel ainda existe; é inacessível até você recriar o nó dev via mknod.
Você pode até criar nós de desenvolvimento de dispositivos nulos adicionais em outro lugar: não importa se você o chama /home/grandma/Recycle Bin, desde que seja um nó de desenvolvimento para o dispositivo nulo, ele funcionará exatamente da mesma maneira que /dev/null.
Na verdade, existem duas APIs de "disco de formato" de alto nível no Windows: SHFormatDrive()e Win32_Volume.Format().
Existem dois por uma razão muito ... bem ... Windows . O primeiro solicita que o Windows Explorer exiba sua caixa de diálogo "Formatar disco" normal, o que significa que funciona em qualquer versão moderna do Windows, mas apenas enquanto um usuário estiver conectado interativamente. O outro pode ser chamado em segundo plano sem a entrada do usuário, mas não foi adicionado ao Windows até o Windows Server 2003. Isso mesmo, o principal comportamento do sistema operacional ficou oculto por trás de uma GUI até 2003, em um mundo para o qual o Unix foi enviado mkfs desde o primeiro dia .
Minha cópia do Unix V5 de 1974 inclui /etc/mkfsum executável PDP-11 vinculado estaticamente com 4136 bytes . (O Unix não teve vínculo dinâmico até o final dos anos 80 , por isso não é como se houvesse uma grande biblioteca em outro lugar fazendo todo o trabalho real.) Seu código-fonte - incluído na imagem do sistema V5 /usr/source/s2/mkfs.c- é um código totalmente independente. programa da linha C. Não há nenhuma #includedeclaração!
Isso significa que você não pode apenas examinar o que mkfsfaz em um nível alto, mas também experimentar o mesmo conjunto de ferramentas com as quais o Unix foi criado, assim como você é Ken Thompson , quatro décadas atrás. Tente isso com o Windows. O mais próximo que você pode chegar hoje é fazer o download do código-fonte do DOS , lançado pela primeira vez em 2014 , que você encontra em apenas uma pilha de fontes de montagem . Ele só será construído com ferramentas obsoletas que você provavelmente não terá disponível e, no final, você terá sua própria cópia do DOS 2.0, um sistema operacional muito menos poderoso que o Unix V5 de 1974 , apesar de ter sido lançado quase uma década depois.
(Por que falar do Unix V5? Porque é o sistema Unix completo mais antigo ainda disponível. Aparentemente, as versões anteriores estão perdendo tempo . Houve um projeto que reuniu um Unix da era V1 / V2, mas parece estar ausente mkfs, apesar da existência da página de manual da V1 vinculada acima, provando que ele deve ter existido em algum lugar, de alguma forma: ou aqueles que montaram este projeto não conseguiram encontrar uma cópia existente mkfspara incluir ou eu sou péssimo em encontrar arquivos sem find(1), o que também não existe nesse sistema . :))
Agora, você pode estar pensando: "Não posso ligar format.com? Não é o mesmo no Windows que ligar mkfspara o Unix?" Infelizmente, não, não é o mesmo, por várias razões:
Primeiro, format.comnão foi projetado para ser roteirizado. Ele solicita que você "pressione ENTER quando estiver pronto", o que significa que você precisa enviar uma tecla Enter para sua entrada ou ela simplesmente trava.
Então, se você deseja algo mais do que um código de status de sucesso / falha, é necessário abrir sua saída padrão para leitura, o que é muito mais complicado no Windows do que precisa ser . (No Unix, tudo nesse artigo vinculado pode ser realizado com uma simples popen(3)chamada.)
Tendo passado por toda essa complicação, format.comé mais difícil analisar o resultado de programas de computador do que o resultado de mkfs, destinado principalmente ao consumo humano.
Se você rastrear o que format.comfaz, você acha que ele faz um monte de chamadas complicado DeviceIoControl(), ufat.dlle tal. Não é simplesmente abrir um arquivo de dispositivo e gravar um novo sistema de arquivos nesse dispositivo. Esse é o tipo de design que você obtém de uma empresa que emprega 126.000 pessoas e precisa continuar empregando-as.
Ao falar sobre dispositivos de loop, falo apenas do Linux, e não do Unix em geral, porque os dispositivos de loop não são portáveis entre sistemas do tipo Unix. Existem mecanismos semelhantes no OS X, BSD etc., mas a sintaxe varia um pouco .
Nos dias em que as unidades de disco eram do tamanho de máquinas de lavar e custavam mais do que o carro de luxo do chefe de departamento, os grandes laboratórios de computação compartilhavam uma proporção maior de seu espaço em disco coletivo em comparação com os ambientes de computação modernos. A capacidade de transferir transparentemente um disco remoto para o sistema de arquivos local tornou esses sistemas distribuídos muito mais fáceis de usar. É aqui que chegamos /usr/share, por exemplo.
Contraste do Windows, em que um disco remoto normalmente é mapeado para uma letra de unidade ou deve ser acessado por um caminho UNC, em vez de ser integrado de forma transparente ao sistema de arquivos local. As letras de unidade oferecem poucas opções para expressão simbólica; não P:se referem ao espaço "público" na BIGSERVER, ou para o diretório "pacotes" no servidor espelho de software? Os caminhos UNC significam que você precisa se lembrar de qual servidor seus arquivos remotos estão, o que fica difícil em uma grande organização com centenas ou milhares de servidores de arquivos.
O Windows não obteve links simbólicos até o Windows Vista, lançado em 2007, que introduziu os links simbólicos NTFS . Os links simbólicos do Windows são um pouco mais poderosos que os links simbólicos do Unix - um recurso do Unix desde 1977 -, pois eles também podem apontar para um compartilhamento remoto de arquivos, não apenas para um caminho local. O Unix fez isso de maneira diferente, via NFS, em 1984 , que se baseia no recurso de ponto de montagem preexistente do Unix , que ele possui desde o início.
Portanto, dependendo de como você o vê, o Windows segue o Unix em aproximadamente 2 ou 3 décadas.
Mesmo assim, os links simbólicos não fazem parte normal da experiência de um usuário do Windows, por alguns motivos.
Primeiro, você pode criá-los apenas com o programa de linha de comando para trásMKLINK . Você não pode criá-los a partir do Windows Explorer, enquanto que os equivalentes UNIX para Windows Explorer normalmente não permitem que você crie links simbólicos.
Segundo, a configuração padrão do Windows impede que usuários normais criem links simbólicos, exigindo que você execute o shell de comando como Administrador ou dê permissão ao usuário para criá-los por um caminho obscuro em uma ferramenta que seu usuário comum nunca viu, muito menos conhece Como usar. (E, diferentemente da maioria dos problemas com privilégios de administrador no Windows, o UAC não ajuda em nada.)
As caixas Linux nem sempre usam uma imagem de disco virtual na sequência de inicialização. Existem várias maneiras diferentes de fazer isso .
man ed
A propósito, os descritores de soquete de rede também são FDs.