Anteriores:
< Trilha Zero >

< Um Disco de Mentira>

Quando se usa um programa de compressão de arquivos em tempo real, um driver é carregado ao ligar a máquina. Toda a vez que é solicitada a gravação de um arquivo, o driver intercepta a solicitação, comprime o arquivo e o grava no disco. Para ler um arquivo previamente comprimido, o driver vai buscá-lo lá onde o gravou, descomprime-o e entrega ao programa no formato original.

Tudo muito simples. Mas alguns pontos merecem atenção. Começando pela impossibilidade de se comprimir todos os arquivos do disco pelo qual se dá o boot. E, para descobrir porque, basta lembrar o que acontece quando a máquina é ligada: primeiro, o POST, ou autoteste de partida. Depois, um programa gravado em ROM procura no disco de boot pelos arquivos do sistema operacional e os carrega na memória. E passa o controle da máquina para o sistema. Que vai então ler o arquivo Config.Sys para carregar seus drivers e residentes. Depois, lê o Autoexec.Bat e executa seus comandos. Só então exibe o prompt indicando que está a nossa disposição.

Já sacou a razão de não se poder comprimir todos os arquivos do disco de boot? Claro que sim: para que os arquivos comprimidos sejam lidos, é necessário que o driver seja carregado, pois sem ele arquivos comprimidos nada significam para o sistema. E o driver só é carregado depois que a linha correspondente do Config.Sys é lida. Portanto, nenhum dos arquivos carregados antes disso pode ser comprimido - ou o sistema não os conseguirá ler. E que arquivos são estes? Os dois que compõem o sistema operacional (os arquivos ocultos Io.Sys e Msdos.Sys do MS-DOS) e pelo menos mais o Config.Sys e o próprio driver do compactador de arquivos. Além, é claro, de todos os drivers incluídos nas linhas do Config.Sys que precedem aquela que contém o driver do programa de compressão em tempo real. Não são muitos, mas trazem uma importante conseqüência: a obrigatória convivência de arquivos comprimidos e não comprimidos em um mesmo disco. Portanto, alguma coisa tem que ser feita para pôr um mínimo de ordem no caos que se formaria caso a mistura não fosse organizada.

Essa coisa é, no fundo, algo muito simples. O sistema operacional e o driver se entendem de forma a que um não se meta naquilo que diz respeito ao outro, ou seja, o driver cuida da leitura e gravação apenas dos arquivos comprimidos enquanto todos os que não o são ficam por conta do sistema operacional. E a maneira como este entendimento é implementado também é simples: durante a instalação do programa de compressão, é criado um arquivo especial. Tão especial que pode ocupar quase todo o disco. Este arquivo, marcado com os atributos de sistema, oculto e apenas para leitura, é aquilo que, na Trilha Zero da semana passada, chamamos de "trecho do disco onde estão os arquivos comprimidos". Nele só quem pode mexer é o driver do programa de compressão em tempo real. O resto do disco - e apenas o resto - fica por conta do DOS.

Este "arquivão", para todos os efeitos práticos, funciona como se fora um disco independente. Na verdade, desde o ponto de vista do sistema operacional, ele é um novo disco. Se foi criado pelo Stacker, seu nome é "Stacvol" e a extensão é "Dsk" para o primeiro, "000", "001" e assim sucessivamente para os demais (mais de um pode ser criado, particularmente se a máquina tem mais de um HD ou diversas partições no mesmo HD). Se foi criado pelo SuperStor, o nome pode ser escolhido pelo usuário durante a instalação (se forem aceitos os parâmetros default na instalação, o nome será "Sspartss" e a extensão será "Add" ou "Swp"). Seja como for, daqui para a frente, para facilitar nossa vida, vamos chamar de "arquivão" a este arquivo que simula um drive.

Pronto: agora já podemos entender melhor como a coisa toda funciona. Quando um programa de compressão em tempo real é instalado, cria no disco rígido um "arquivão" e diz para o sistema operacional não mexer nele. Protege-o, fazendo com que tenha os atributos de sistema, apenas para leitura e oculto, de modo que não apareça nas listagens de diretório nem possa ser inadvertidamente apagado ou modificado pelo usuário ou por outros programas. E deste ponto em diante, só quem lê ou grava dados no arquivão é o driver do programa de compressão. Para isto ele faz com que seja atribuído ao arquivão um designador de disco (uma "letra"), como se houvesse sido criada uma nova partição no disco rígido. A partir deste ponto, os programas, o sistema operacional e o usuário passam a "enxergar" o arquivão como se fosse um novo disco.

Semana que vem vamos acompanhar passo a passo a instalação de um programa compressor de arquivos em um disco rígido, e tudo ficará mais claro. Por ora, o importante é entender que o processo é semelhante à subdivisão de um HD em partições: tem-se na verdade um único HD, porém dividido de tal forma que cada "pedaço" é acessado por uma letra diferente, como se fossem discos independentes. Por exemplo: um arquivão destes, criado no disco C, simula um novo disco rígido, que assume o designador "D", enquanto os arquivos que não foram comprimidos permanecem no disco C (se você usa um destes programas e os arquivos, mesmo depois de comprimidos, ainda aparecem no disco C, não se preocupe: justamente para evitar problemas com a configuração de aplicativos previamente instalados, os programas de compressão em tempo real usam um utilitário auxiliar que permite "trocar" os designadores de disco, de forma que o disco C passa a ser "enxergado" como drive D e o arquivão, onde foram gravados em forma comprimida os arquivos que estavam originalmente no disco C, mantém o designador C).

A diferença básica entre uma partição de um disco rígido criada com o programa Fdisk e o arquivão criado pelos programas de compressão em tempo real, é que as partições são rigorosamente independentes, jamais se superpondo, enquanto o arquivão está, de fato, dentro do drive onde foi criado. Mas como não pode ser acessado, exceto por seu driver, nem aparece nas listagens de diretório, isso não faz grande diferença (mas se você tiver um programa que mostre arquivos ocultos, como o XTree, ou se usar o parâmetro "/a" no comando "dir", seu nome e tamanho serão exibidos).

A coisa está meio confusa? Não se preocupe. Semana que vem, quando acompanharmos a instalação de um programa de compressão de arquivos em tempo real, tudo ficará mais claro. Aguarde.

OS/2: Dan Finerty, da IBM/Canadá, vai apresentar palestra sobre o OS/2 2.0 nesta quarta, dia 9, às 14:30hs no auditório do Rio Data Center (RDC) da PUC/Rio, na Marquês de S. Vicente, Gávea. A palestra, com tradução simultânea, é aberta ao público: basta se inscrever na hora (e concorrer: vai ter sorteio de OS/2).

B. Piropo