Qual é o conceito de criar um arquivo com zero bytes no Linux?

Se eu fizer o seguinte:

touch /tmp/test

e depois executar

ls -la /tmp/

Eu pude ver o testarquivo com 0 bytes no diretório

Mas como o sistema operacional lida com um conceito de 0 bytes . Se eu colocá-lo em termos leigos:

0 Bytes não possui memória, portanto, nada é criado.

A criação de um arquivo deve ou deve exigir pelo menos certa memória, certo?

Um arquivo é (aproximadamente) três coisas separadas:

• Um "inode", uma estrutura de metadados que controla quem possui o arquivo, as permissões e uma lista de blocos no disco que realmente contêm os dados.
• Uma ou mais entradas de diretório (os nomes dos arquivos) que apontam para esse inode
• Os próprios blocos de dados reais

Ao criar um arquivo vazio, você cria apenas o inode e uma entrada de diretório apontando para esse inode. O mesmo para arquivos esparsos ( dd if=/dev/null of=sparse_file bs=10M seek=1).

Ao criar hardlinks para um arquivo existente, basta criar entradas de diretório adicionais que apontam para o mesmo inode.

Eu simplifiquei as coisas aqui, mas você entendeu.

touchcriará um inode e ls -iou statmostrará informações sobre o inode:

$ touch test
$ ls -i test
28971114 test
$ stat test
  File: ‘test’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 28971114    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/1000)   Gid: ( 1000/1000)
Access: 2017-03-28 17:38:07.221131925 +0200
Modify: 2017-03-28 17:38:07.221131925 +0200
Change: 2017-03-28 17:38:07.221131925 +0200
 Birth: -

Observe que testusa 0 blocos. Para armazenar os dados exibidos, o inode usa alguns bytes. Esses bytes são armazenados na tabela de inodes. Veja na página ext2 um exemplo de estrutura de inode .

ls(ou bem, a stat(2)chamada do sistema) informa o tamanho do conteúdo do arquivo. Quanto espaço o sistema de arquivos precisa para a contabilidade não faz parte disso e, como detalhe de implementação, não é algo que os programas em geral devam se preocupar ou mesmo conhecer. Tornar os detalhes da implementação visíveis tornaria a abstração do sistema de arquivos menos útil.

O arquivo, por si só, não ocupa espaço, mas o sistema de arquivos, armazenando o nome do arquivo, a localização, os direitos de acesso a ele e similares.

Resposta simples: porque é definido dessa maneira.

Resposta mais longa: é definida dessa maneira porque algumas operações são conceitualmente mais simples:

• Se um arquivo contiver 20 letras "A" e você remover todos os "A" s, o arquivo ficará 20 bytes mais curto. A mesma operação em um arquivo que consiste apenas em "AAAAAAAAAAAAAAAAAAA" teria que lidar com o caso especial de um arquivo que desapareceu.
• Mais praticamente, a exclusão da última linha de um arquivo de texto precisaria ser especificada.
• Os editores de texto que fazem backup regularmente precisam de um código de caso especial para lidar com a situação em que o usuário pode excluir a última linha, almoçar e voltar e adicionar outra linha. Outras complicações surgem se outros usuários criarem um arquivo com esse nome nesse meio tempo.

Você pode fazer mais coisas: * Os arquivos de log de erros tendem a ser criados vazios, a serem preenchidos se e somente se ocorrer um erro. * Para descobrir quantos erros ocorreram, conte o número de linhas nos arquivos de log. Se o arquivo de log estiver vazio, o número de erros será zero, o que faz todo o sentido. * Às vezes você vê arquivos onde todo o texto relevante está no nome do arquivo, por exemplo this-is-the-logging-directory. Isso evita que administradores excessivos excluam diretórios vazios após a instalação e também evita erros nos casos em que um programa ou usuário cria acidentalmente um arquivo no qual o programa gostaria de ver um diretório posteriormente. O gitprograma (e outros) tendem a ignorar diretórios vazios e, se um projeto / administrador / usuário quiser ter um registro de que o diretório existe, mesmo que ainda não tenha conteúdo útil, você poderá ver um arquivo vazio chamadoemptyou empty.directory.

Nenhuma operação se torna mais complicada:

• Concatenando arquivos: este é apenas um no-op com um arquivo vazio.
• Procurando por uma sequência em um arquivo: isso é coberto pelo caso padrão de "se o arquivo for menor que o termo de pesquisa, não poderá conter o termo de pesquisa".
• Lendo do arquivo: os programas precisam lidar com o final do arquivo antes de obter o que esperavam; então, novamente, o caso de um arquivo de tamanho zero não envolve um pensamento extra para o programador: ele apenas atingirá o final de -arquivo desde o início.

No caso de arquivos, o aspecto "existe um arquivo gravado em algum lugar" (inode e / ou nome do arquivo) é complementado pelas considerações acima, mas os sistemas de arquivos não o fariam se os arquivos vazios fossem inúteis.

Em geral, todos os motivos acima, exceto aqueles relacionados a nomes de arquivos, se aplicam a sequências. Mais notavelmente para strings, que são seqüências de caracteres: strings de comprimento zero são comuns dentro de programas. Seqüência de caracteres não é permitida no nível do usuário se não fizer sentido: um nome de arquivo é uma sequência e a maioria dos sistemas de arquivos não permite uma sequência vazia como nome de arquivo; internamente, ao criar nomes de arquivos a partir de fragmentos, o programa pode ter uma sequência vazia como um dos fragmentos.

Usando a analogia mais simples:

Vamos comparar um arquivo com, digamos, um copo de água.

'touch / tmp / test' é como criar um copo vazio, sem água. O copo está vazio, então o tamanho é zero. Mas o vidro existe.

Na linguagem do sistema de arquivos, o vidro é o metadado, enquanto o conteúdo do vidro é o dado. Os metadados contêm todos os tipos de coisas, como mencionado nas postagens anteriores.

Arquivos de tamanho zero podem ser úteis. Um exemplo é usá-los como uma trilha de navegação, onde sua mera existência pode ser usada para indicar algum tipo de estado (ou seja, se o arquivo existir: faça alguma coisa; se não: ignore).

Pense da seguinte maneira: diga que um programa está rastreando consultas SQL enviadas ao seu servidor. O programa deseja indicar que está registrando solicitações em um arquivo de texto sem formatação, mas nenhuma solicitação foi registrada ainda. Como deve ser isso? Eu diria que deveria ser um arquivo de tamanho zero em /var/log/acme-sql-server/queries.log. Dessa forma, você pode descobrir quando o log iniciou (o horário de criação do arquivo), quando foi atualizado pela última vez (ou seja, quando foi criado), quantas consultas foram registradas (número de novas linhas no arquivo = 0) e quem está fazendo o log. (SQL Server Acme). Para casos como esse, é útil ter o conceito de um arquivo vazio que, no entanto, existe em um local específico.