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

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.

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.

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 :-)

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.)