Estou lendo este tutorial do Unix e me deparei com esta citação ...
Devemos observar aqui que um diretório é apenas um tipo especial de arquivo.
... mas nenhuma explicação ou detalhes são fornecidos. Como um diretório é realmente apenas um arquivo?
Respostas:
Muitas entidades nos sistemas operacionais no estilo * nix (e outros) são consideradas arquivos ou têm um aspecto definidor de arquivo, mesmo que não sejam necessariamente uma sequência de bytes armazenados em um sistema de arquivos. Exatamente como os diretórios são implementados depende do tipo de sistema de arquivos, mas geralmente o que eles contêm, considerado como uma lista, é uma sequência de bytes armazenados, portanto, nesse sentido, eles não são tão especiais.
Uma maneira de definir o que é um "arquivo" em um contexto * nix é que ele possui um descritor de arquivo associado a ele. De acordo com o artigo da Wikipedia, um descritor de arquivo
é um indicador abstrato usado para acessar um arquivo ou outro recurso de entrada / saída , como um cano ou conexão de rede ...
Em outras palavras, eles se referem a vários tipos de recursos de / para os quais uma sequência de bytes pode ser lida / gravada, embora a origem / destino dessa sequência não seja especificada. Em outras palavras, o "onde" do recurso pode ser qualquer coisa. O que define é que é um canal de informação. Isso é parte do motivo de se dizer às vezes que no unix "tudo é um arquivo". Você não deve interpretar isso completamente literalmente, mas vale a pena considerar seriamente. No caso de um diretório, essas informações pertencem ao que está no diretório e, em um nível inferior de implementação, como localizá-las no sistema de arquivos.
Diretórios são meio especiais nesse sentido, porque no código C nativo eles não são ostensivamente associados a um descritor de arquivo; a API POSIX usa um tipo especial de identificador de fluxo DIR*,. No entanto, esse tipo tem de fato um descritor subjacente que pode ser recuperado . Os descritores são gerenciados pelo kernel e acessá-los sempre envolve chamadas de sistema, portanto, outro aspecto do que é um descritor é que ele é um canal controlado pelo kernel do sistema operacional. Eles têm números únicos (por processo) começando com 0, que geralmente é o descritor para o fluxo de entrada padrão .
openat, fstatat, etc.) que usam descritores de arquivos referentes aos diretórios.
fsync()criar um diretório somente leitura (!) Fd, e ele tem um efeito bem definido (especificamente, sincroniza a criação / renomeação / exclusão de arquivos no diretório especificado para o disco, uma etapa teoricamente necessária na "gravação" para um arquivo temporário e renomeie-o sobre o "idioma original).
Na maneira Unix de fazer as coisas: tudo é um arquivo.
Um diretório é um (de muitos) tipos de arquivos especiais. Não contém dados. Em vez disso, ele contém ponteiros para todos os arquivos contidos no diretório.
Outros tipos de arquivos especiais:
Porém, como são considerados "arquivos", você pode lsrenomeá-los e movê-los e, dependendo do tipo de arquivo especial, enviar dados para / deles.
Minha resposta é mera reminiscência, mas nos Unixes antigos de 199x, dos quais havia muitos, diretórios eram arquivos, apenas marcavam "diretório" em algum lugar do inode no disco.
Você pode abrir um diretório com algo parecido open(".", O_RDONLY)e recuperar um descritor de arquivo utilizável. Você poderia analisar o conteúdo se folhear /usr/includee encontrar a definição correta da estrutura. Eu sei que fiz isso nos sistemas SunOS 4.1.x, no sistema de arquivos EFS da SGI e em qualquer estação de trabalho Mips-CPU da DEC para um sistema de arquivos, provavelmente BSD4.2 FFS.
Essa foi uma experiência ruim. A padronização em uma camada do sistema de arquivos virtual é uma boa coisa para portabilidade, mesmo que os diretórios não sejam mais arquivos estritos. As camadas VFS permitem experimentar sistemas de arquivos em que diretórios não são arquivos, como ReiserFS ou NFS.
cp --link dir1/* dir2, embora eu não tenha certeza sobre sua usabilidade.
Um diretório é especial, pois possui o 'd' em seu modo, informando ao sistema de arquivos que ele deve interpretar seu conteúdo como uma lista de outros arquivos contidos no diretório, em vez de um arquivo comum, que é apenas uma sequência de bytes a ser lido pelo aplicativo. Isso é tudo.
Diretórios são arquivos porque os sistemas linux empregam o modelo de E / S universal . No modelo, tudo no sistema é um arquivo e pode ser acessado com as mesmas chamadas do sistema e vários comandos.
Eles são do tipo especial porque seus nós-i têm a marca do tipo de arquivo e têm uma estrutura especial para serem uma tabela de nomes de arquivos e links para outros nós-i. Esses pares de nome de arquivo-link, também conhecidos como "hardlinks", no nó i de um diretório enumeram os arquivos "dentro" do diretório.
Diretórios são apenas para organizar arquivos. Quando um arquivo é "movido" de um diretório para outro, o próprio arquivo não é realocado no disco. É apenas que uma entrada em um diretório i-nodes é removida e gravada em outro diretório i-node.
A resposta aceita não está completamente correta. nos sistemas POSIX, "Inodes" aponta para arquivos e diretórios. Os descritores de arquivo são exclusivos apenas de um processo e não de um sistema. Os inodes, no entanto, são únicos, embora mais de um inode possa apontar para um único arquivo. Teria comentado sobre a resposta aceita, mas não pôde devido à restrição de representante.
ls -l >test.txt;ln -vf test.txt test2.txt;ls -li test.txt test2.txt. Então você verá que os links físicos têm o mesmo número de inode.
fork()s, seu processo filho terá (exceto alguma circunstância especial, ou seja, uma O_CLOEXECflag) exatamente as mesmas entidades de filedescriptor do processo original. Outro exemplo: os processos filho do apache estão listen()no mesmo descritor de arquivo de soquete. Mas essa resposta não é sobre os descritores de arquivo, que são uma estrutura de dados interna ao kernel e existem apenas na memória do kernel. Essa resposta ( falsa ) é sobre as entradas de diretório e os inodes, são entidades em disco (ou seja, são bytes físicos no disco rígido).
fork()acontecer e o processo filho seek()( close()s), isso não afetará o descritor de arquivo do pai. Então, estou pensando agora, que os descritores de arquivo são apenas estruturas parcialmente process-private. Mas essa pergunta não é sobre eles, é sobre os dirents / inodes e eu estou comentando sobre uma resposta totalmente falsa a essa pergunta.