La sfida di Kernighan e Pike: come mettere una barra in un nome file?

Ho appena incontrato la seguente domanda in Unix Programming Environment , il classico libro di Kernighan e Pike su Unix (ho trovato il testo qui sotto a pagina 79 dell'edizione dell'anno 1984, ISBN: 0-13-937699-2):

Esercizio 3-6. (Domanda a trabocchetto) Come si ottiene un / in un nome di file (ovvero, un / che non separa i componenti del percorso?

Lavoro con Linux da anni, sia come utente finale che come programmatore, ma non posso rispondere a questa domanda. Non c'è modo di inserire barre nei nomi dei file, è assolutamente proibito dal kernel. Puoi patchare il tuo filesystem tramite l'accesso al dispositivo di blocco o usare caratteri simili dall'Unicode, ma quelli non sono soluzioni.

Comprendo che Linux ≠ Unix, ma lo stesso principio dovrebbe applicarsi, poiché il sistema deve essere in grado di estrarre in modo inequivocabile la gerarchia di directory dai percorsi.

Qualcuno sa cosa hanno pensato esattamente Kernighan e Pike quando si ponevano queste domande? Qual era la presunta risposta? Qual è esattamente il 'trucco'? O forse il sistema Unix originale ha semplicemente permesso di sfuggire a questa barra in qualche modo?

UPD:

Ho contattato Brian Kernighan in merito alla domanda ed è quello che ha risposto:

La risposta è (o era) "Non puoi".

Quindi, Timothy Martin aveva ragione e ottiene il segno di spunta verde.

Forse la risposta è uguale alla parte della risposta in questa domanda trabocchetto:
come si scende da un elefante? Non Lo prendi da un'oca.

Da "La pratica della programmazione" di Brian W. Kernighan e Rob Pike, cap. 6, pag. 158:

Quando Steve Bourne stava scrivendo la sua shell Unix (che divenne nota come shell Bourne), creò una directory di 254 file con nomi di un carattere, uno per ogni valore di byte tranne '\ 0' e barra, i due caratteri che non può apparire nei nomi di file Unix.

L'ho fatto. Questo era su un sistema UNIX in esecuzione su un PDP-11 intorno al 1980. Ho creato un file chiamato "WhatXNow?". Ho quindi usato un "editor" di file binario per modificare il dispositivo disco e cambiare la "X" in un "/" nell'inode (con il file system smontato).

La vittima non ha mai capito come rimuoverlo.

Modifica: whoops, Barmar ha ragione, non sono riuscito a vedere la linea lì dentro per non patchare il dispositivo. E sì, era la directory che ho modificato, non l'inode. È passato un po 'di tempo :-)

Qualsiasi scenario in cui /(più precisamente, un byte - non un carattere - con valore 0x2f; quasi tutti i kernel Unix sono intenzionalmente ignari della codifica dei caratteri) trova la sua strada in una voce di directory, senza che i blocchi di dischi grezzi siano stati manipolati a mano, è senza dubbio un bug nel kernel.

Tali bug si verificano di volta in volta. Un caso per cui ricordo di aver letto le note sulla patch è che alcune iterazioni degli anni '90 di ... Voglio dire Solaris, ma potrebbe essere sbagliato ... offrivano un server per l'AppleTalk Filing Protocol (AFP), che era l'equivalente classico di MacOS di NFS . Il problema era che su MacOS classico sei perfettamente autorizzato a inserire /un componente pathname; il separatore di directory :invece è . Il server AFP avrebbe dovuto fare l'equivalente morale di tr :/ /:quando mappava i percorsi inviati dai client su file sul suo disco, ma mancavano un paio di percorsi di codice e, poiché il server era implementato all'interno del kernel, poteva effettivamente scrivere voci di directory errate.

(Vedi comp.unix FAQ # 2.2 , la sottosezione che inizia "Che cosa succede se il nome del file ha un '/' in esso?", Per una versione più lunga di quanto sopra.)