Desafio de Kernighan e Pike: como colocar uma barra em um nome de arquivo?

23

Acabei de encontrar a seguinte pergunta no Unix Programming Environment , o livro clássico de Kernighan e Pike sobre Unix (encontrei o texto abaixo na p. 79 da edição do ano 1984, ISBN: 0-13-937699-2):

Exercício 3-6. (Pergunta de truque) Como você coloca um / em um nome de arquivo (ou seja, um / que não separa os componentes do caminho?

Trabalho com Linux há anos, tanto como usuário final quanto como programador, mas não consigo responder a essa pergunta. Não há como colocar barras nos nomes de arquivos, é absolutamente proibido pelo kernel. Você pode corrigir seu sistema de arquivos através do acesso ao dispositivo de bloco ou usar caracteres com aparência semelhante no Unicode, mas essas não são soluções.

Eu entendo que o Linux ≠ Unix, mas o mesmo princípio deve se aplicar, já que o sistema deve ser capaz de extrair inequivocamente a hierarquia de diretórios dos caminhos.

Alguém sabe o que exatamente Kernighan e Pike pensaram ao fazer essas perguntas? Qual foi a suposta resposta? O que exatamente é o 'truque'? Ou talvez o sistema Unix original simplesmente tenha escapado dessa barra de alguma forma?

UPD:

Entrei em contato com Brian Kernighan sobre a pergunta e foi isso que ele respondeu:

A resposta é (ou foi): "Você não pode".

Por isso, Timothy Martin estava certo e recebe o sinal verde.

firegurafiku
fonte
3
Relacionado (não duplicado), um caso em que alguém realmente conseguiu: Como excluir um arquivo chamado “filen / ame” (com barra) em um sistema de arquivos ext4 no debugfs?
22617 Michael Homer
Hmm. Talvez você possa criar um arquivo contendo letras minúsculas ae forçar seu sistema a pensar que o sistema de arquivos está em um código de idioma EBCDIC? ASCII aé 0x61, que corresponde ao /EBCDIC (página de códigos 37)
Fox
O livro em si diz que é uma pergunta complicada? Nesse caso, acho que praticamente confirma que você não conseguirá encontrar uma maneira específica de fazê-lo, deixando as idéias prontas para uso que você já declarou.
Ilkkachu

Respostas:

12

Talvez a resposta seja a mesma que parte da resposta nesta pergunta complicada:
Como você desce de um elefante? Você não Você pega de ganso.

De "The Practice of Programming", de Brian W. Kernighan e Rob Pike, cap. 6, pág. 158:

Quando Steve Bourne estava escrevendo seu shell Unix (que ficou conhecido como shell Bourne), ele criou um diretório de 254 arquivos com nomes de um caractere, um para cada valor de byte, exceto '\ 0' e barra, os dois caracteres que não pode aparecer nos nomes de arquivo Unix.

Timothy Martin
fonte
3
Obrigado por me ensinar essa piada. Provavelmente, pode servir como um teste de fluência em inglês (que acabei de falhar).
Firegurafiku
Você estava certa. Veja UPD.
Firegurafiku
1
@firegurafiku explica Joke .
Isaac
5

Eu fiz isso. Isso estava em um sistema UNIX em execução no PDP-11, por volta de 1980. Criei um arquivo chamado "WhatXNow?". Em seguida, usei um "editor" de arquivo binário para editar o dispositivo de disco e alterar o "X" para um "/" no inode (com o sistema de arquivos desmontado).

A vítima nunca descobriu como removê-lo.

Edit: whoops, Barmar está certo, não consegui ver a linha lá sobre não corrigir o dispositivo. E sim, foi o diretório que editei, não o inode. Faz algum tempo :-)

Topher Eliot
fonte
1
Os nomes de arquivos não estão no inode, estão no arquivo especial do diretório.
Barmar
1
Eu suspeito fsckque teria removido.
Barmar
1
A pergunta diz: Você pode corrigir seu sistema de arquivos via acesso ao dispositivo de bloco ou usar caracteres de aparência semelhante no Unicode, mas essas não são soluções. Não é isso que você está descrevendo na sua resposta?
Barmar
@ Barmar: Hmm, talvez eu esteja pensando demais na questão e remendar o sistema de arquivos é a solução que foi criada? Eu não sei.
Firegurafiku #
Aposto que essa foi a resposta. Lembro-me de quando você podia ler diretórios. Talvez, eras atrás, o root pudesse escrevê-los.
197 Joshua
1

Qualquer cenário em que /(mais precisamente, um byte - não um caractere - com valor 0x2f; quase todos os kernels do Unix são intencionalmente alheios à codificação de caracteres) encontra seu caminho para uma entrada de diretório, sem que os blocos de disco bruto tenham sido manipulados manualmente, é inquestionavelmente um bug no kernel.

Tais erros acontecem de tempos em tempos. Um caso para o qual lembro de ler as notas de patch é que algumas iterações da década de 1990 de ... quero dizer Solaris, mas isso pode estar errado ... ofereceram um servidor para o AppleTalk Filing Protocol (AFP), que era o equivalente clássico do MacOS ao NFS . O problema era que, no MacOS clássico, você pode perfeitamente colocar /um componente de nome de caminho; o separador de diretório está em seu :lugar. O servidor AFP deveria fazer o equivalente moral tr :/ /:ao mapear nomes de caminho enviados pelos clientes em arquivos em seu disco, mas eles perderam alguns caminhos de código e, como o servidor foi implementado dentro do kernel, ele pode escrever entradas de diretório incorretas.

(Consulte a FAQ do comp.unix # 2.2 , a subseção que começa com "E se o nome do arquivo tiver '/'?", Para uma versão mais longa do anterior.)

zwol
fonte