octal dump do diretório

Question

Eu recebi uma cópia do Ambiente de Programação Unix por Kernighan e Pike de uma venda de garagem. Estou muito interessado no capítulo sobre o sistema de arquivos UNIX. Naturalmente, também achei esta passagem muito interessante:

The time has come to look at the bytes in a directory:

$ od -cb .
0000000    4    ;    .   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%   %bl0ck_qu0te%
          064  073  056  000  000  000  000  000  000  000  000  000  000  000  000  000
....

Foi muito longo, então não vou digitar tudo. A essência disso era que exibia o diretório da maneira como ele era armazenado no sistema. Eu rapidamente corri para o meu laptop (Debian) para tentar fazer isso. Eu digitei o comando como estava no livro.

$ od -cb .
od: .: read error: Is a directory
0000000

Obviamente, não me deixa ver o conteúdo bruto do diretório. Então aqui está a minha pergunta.

O kernel do Linux armazena diretórios de uma maneira diferente do que o kernel original do UNIX fez? Se não, por que há a necessidade de ocultar os bytes reais do diretório do usuário?

    

Answer 1

Cada tipo de sistema de arquivos armazena os diretórios de uma maneira diferente. Existem muitos tipos diferentes de sistemas de arquivos com características diferentes - bons para alta taxa de transferência, bons para alta simultaneidade, bons para ambientes de memória limitada, diferentes comprometimentos entre leitura e gravação, entre complexidade e estabilidade, etc. Seu livro descreve um sistema de arquivos usado no início Sistemas Unix. Sistemas modernos suportam muitos sistemas de arquivos diferentes.

As versões iniciais do Unix tinham muita manipulação do sistema de arquivos fora do kernel. Por exemplo, mkdir e rmdir funcionaram editando diretamente algumas estruturas de dados do sistema de arquivos. Isso foi rapidamente substituído por uma interface uniforme de acesso ao diretório, a opendir / readdir / a família closedir , que permitia que os aplicativos manipulassem diretórios sem precisar saber como eles eram implementados sob o capô.

O motivo pelo qual você não pode ler o conteúdo do diretório no Linux não é porque eles precisam ser ocultados, mas porque os recursos existem apenas se forem implementados, e esse recurso é inútil e tem um custo. Dado que o formato depende do sistema de arquivos, é um recurso sem sentido: um programa não pode saber o formato do que está lendo. Não é um recurso completamente trivial para suportar: alguns sistemas de arquivos organizam diretórios de maneiras que não são apenas um fluxo de bytes, por exemplo, pode ser organizado como um B-tree . Algumas variantes do Unix ainda permitem que os aplicativos leiam o conteúdo do diretório diretamente, para compatibilidade com versões anteriores, mas o Linux não tem esse recurso (e nunca teve tanto quanto me lembro - já era um recurso obsoleto no início dos anos 90). >     

Answer 2

Sim, mas:

Os
• sistemas modernos armazenam nomes de arquivos de maneira diferente. No Unix original, os nomes eram limitados a 14 caracteres, com 2 bytes para inode.
• a interface para o diretório é via funções opendir , readdir , closedir em vez de open , read , close para refletir a mudança na organização.
• porque ninguém tem uma necessidade prática de ler entradas de diretório de 16 bytes, os projetistas omitiram a capacidade de ler arquivos de diretórios não processados de programas projetados para ler arquivos .

Leitura adicional:

• Howto: C Programação com diretórios no Linux
• pergunta sobre opendir, readdir, etc. , tópico da Usenet em 1990 discutindo a implementação moderna de opendir , etc.

Answer 3

Sim, o kernel do Linux usa o VFS para abstrair diferentes sistemas de arquivos e não permite que você use read(2) em um diretório.

Mas, se você estiver realmente interessado no conteúdo bruto de um diretório no sistema de arquivos Linux EXT2 / 3/4, poderá usar o utilitário debugfs(8) de e2fsprogs , o que permitirá ler ou descarregar diretórios como arquivos regulares. .