Desafío Kernighan y Pike: ¿cómo poner una barra en un nombre de archivo?

Acabo de encontrar la siguiente pregunta en Unix Programming Environment , el libro clásico de Kernighan y Pike sobre Unix (encontré el texto a continuación en la p. 79 de la edición del año 1984, ISBN: 0-13-937699-2):

Ejercicio 3-6. (Pregunta capciosa) ¿Cómo se obtiene un / en un nombre de archivo (es decir, un / que no separa los componentes de la ruta?

He estado trabajando con Linux durante años, tanto como usuario final como programador, pero no puedo responder a esta pregunta. No hay forma de poner barras en los nombres de archivo, está absolutamente prohibido por el núcleo. Puede parchear su sistema de archivos a través del bloqueo del acceso al dispositivo o usar caracteres de aspecto similar de Unicode, pero esas no son soluciones.

Entiendo que Linux ≠ Unix, pero el mismo principio debería aplicarse, ya que el sistema debe poder extraer sin ambigüedad la jerarquía de directorios de las rutas.

¿Alguien sabe qué pensaron exactamente Kernighan y Pike al hacer estas preguntas? ¿Cuál fue la supuesta respuesta? ¿Qué es exactamente el "truco"? ¿O tal vez el sistema original de Unix simplemente permitió escapar de esta barra de alguna manera?

UPD:

Me puse en contacto con Brian Kernighan sobre la pregunta y eso fue lo que respondió:

La respuesta es (o fue) "No puedes".

Por lo tanto, Timothy Martin tenía razón y obtiene la marca verde.

Tal vez la respuesta sea la misma que parte de la respuesta en esta pregunta capciosa:
¿Cómo se baja de un elefante? Usted no Lo obtienes de un ganso.

De "La práctica de la programación" de Brian W. Kernighan y Rob Pike, Ch. 6, pág. 158:

Cuando Steve Bourne estaba escribiendo su shell Unix (que se conoció como el shell Bourne), creó un directorio de 254 archivos con nombres de un carácter, uno para cada valor de byte excepto '\ 0' y barra diagonal, los dos caracteres que no puede aparecer en los nombres de archivo Unix.

He hecho esto Esto fue en un sistema UNIX que se ejecuta en un PDP-11 en algún momento alrededor de 1980. Creé un archivo llamado "WhatXNow?". Luego usé un "editor" de archivos binarios para editar el dispositivo de disco y cambiar la "X" a "/" en el inodo (con el sistema de archivos desmontado).

La víctima nunca descubrió cómo quitarlo.

Editar: whoops, Barmar tiene razón, no pude ver la línea allí sobre no parchear el dispositivo. Y sí, fue el directorio que edité, no el inodo. Ha sido un tiempo :-)

Cualquier escenario en el que /(más precisamente, un byte, no un carácter, con valor 0x2f; casi todos los núcleos de Unix son intencionalmente ajenos a la codificación de caracteres) encuentra su camino en una entrada de directorio, sin que los bloques de disco sin procesar hayan sido manipulados a mano, es indudablemente Un error en el núcleo.

Tales errores ocurren de vez en cuando. Un caso para el que recuerdo haber leído las notas del parche es que algunas iteraciones de la década de 1990 de ... Quiero decir Solaris, pero eso podría estar mal ... ofreció un servidor para el AppleTalk Filing Protocol (AFP), que era el equivalente de NFS clásico de MacOS . El problema era que, en MacOS clásico, se te permite poner perfectamente /un componente de nombre de ruta; el separador de directorio es en su :lugar. Se suponía que el servidor AFP debía hacer el equivalente moral de tr :/ /:cuando asignaba los nombres de ruta enviados por los clientes a los archivos en su disco, pero se perdieron un par de rutas de código, y debido a que el servidor se implementó dentro del núcleo, en realidad podría escribir entradas de directorio incorrectas.

(Ver comp.unix FAQ # 2.2 , la subsección que comienza "¿Qué pasa si el nombre de archivo tiene un '/' en él?", Para una versión más larga de lo anterior.)