Défi Kernighan et Pike: comment mettre une barre oblique dans un nom de fichier?

Je viens de rencontrer la question suivante dans Unix Programming Environment , le livre classique de Kernighan et Pike sur Unix (j'ai trouvé le texte ci-dessous à la p. 79 de l'édition 1984, ISBN: 0-13-937699-2):

Exercice 3-6.(Question piège) Comment obtenir un / dans un nom de fichier (c'est-à-dire un / qui ne sépare pas les composants du chemin?

Je travaille avec Linux depuis des années, à la fois en tant qu'utilisateur final et programmeur, mais je ne peux pas répondre à cette question. Il y a aucun moyen de mettre des barres obliques dans les noms de fichiers, c'est absolument interdit par le noyau. Vous pouvez patcher votre système de fichiers via l'accès au périphérique de bloc, ou utiliser des caractères d'aspect similaire à partir de l'Unicode, mais ce ne sont pas des solutions.

Je comprends que Linux ≠ Unix, mais le même principe devrait s'appliquer, car le système doit être capable d'extraire sans ambiguïté la hiérarchie des répertoires des chemins.

Quelqu'un sait-il exactement à quoi Kernighan et Pike ont pensé en posant ces questions? Quelle était la supposée réponse? Quel est exactement le «truc»? Ou peut-être que le système Unix original a simplement échappé à cette barre oblique?

UPD:

J'ai contacté Brian Kernighan à propos de la question et c'est ce qu'il a répondu:

La réponse est (ou était) "Vous ne pouvez pas."

Par conséquent, Timothy Martin avait raison et obtient la coche verte.

filenames slash historical-unix

— firegurafiku
source

Lié (pas en double), un cas où quelqu'un l'a réellement géré: Comment supprimer un fichier nommé «filen / ame» (avec barre oblique) sur un système de fichiers ext4 dans debugfs?

— Michael Homer

Un autre connexe unix.stackexchange.com/questions/328928/…

— Philip Kirkbride

Hmm. Peut-être pourriez-vous créer un fichier contenant des minuscules aet contraindre votre système à penser que le système de fichiers se trouve dans un environnement local EBCDIC? ASCII aest 0x61, ce qui correspond à /EBCDIC (page de codes 37)

— Fox

Le livre lui-même dit-il que c'est une question piège? Si c'est le cas, je pense que cela confirme à peu près que vous ne serez pas en mesure de trouver un moyen de le faire par conception, en laissant les idées prêtes à l'emploi que vous avez déjà énoncées.

— ilkkachu

Réponses:

Peut-être que la réponse est la même que celle qui fait partie de cette question piège:
comment descendez-vous d'un éléphant? Non. Vous l'obtenez d'une oie.

Extrait de "The Practice of Programming" de Brian W. Kernighan et Rob Pike, Ch. 6, p. 158:

Lorsque Steve Bourne écrivait son shell Unix (qui devint plus tard le shell Bourne), il a fait un répertoire de 254 fichiers avec des noms à un caractère, un pour chaque valeur d'octet sauf '\ 0' et la barre oblique, les deux caractères qui ne peut pas apparaître dans les noms de fichiers Unix.

— Timothy Martin
source

Merci de m'avoir appris cette blague. Il peut probablement servir de test de maîtrise de l'anglais (que je viens d'échouer).

— firegurafiku

Tu avais raison. Voir UPD.

— firegurafiku

@firegurafiku explique Joke .

— Isaac

J'ai fait ça. C'était sur un système UNIX fonctionnant sur un PDP-11 vers 1980. J'ai créé un fichier appelé "WhatXNow?". J'ai ensuite utilisé un "éditeur" de fichiers binaires pour modifier le périphérique de disque et changer le "X" en "/" dans l'inode (avec le système de fichiers démonté).

La victime n'a jamais compris comment l'enlever.

Edit: whoops, Barmar a raison, je n'ai pas vu la ligne à propos de ne pas patcher l'appareil. Et oui, c'est le répertoire que j'ai édité, pas l'inode. Cela fait longtemps :-)

— Topher Eliot
source

Les noms de fichiers ne sont pas dans l'inode, ils sont dans le fichier spécial du répertoire.

— Barmar

Je soupçonne l' fsckaurait supprimé.

— Barmar

La question dit que vous pouvez patcher votre système de fichiers via l'accès au périphérique de bloc, ou utiliser des caractères similaires à partir de l'Unicode, mais ce ne sont pas des solutions. N'est-ce pas ce que vous décrivez dans votre réponse?

— Barmar

@Barmar: Hmm, peut-être que je repense trop à la question et que le correctif du système de fichiers est la solution qui était destinée? Je ne sais pas.

— firegurafiku

Je parie que c'était la réponse. Je me souviens quand on pouvait lire des répertoires. Il y a peut-être longtemps que root pourrait les écrire.

— Joshua

Tout scénario où/ (plus précisément, un octet - pas un caractère - avec la valeur 0x2f; presque tous les noyaux Unix sont intentionnellement inconscients du codage de caractères) trouve son chemin dans une entrée de répertoire, sans que les blocs de disque bruts aient été manipulés à la main, est incontestablement un bug dans le noyau.

De tels bogues se produisent de temps en temps. Un cas pour lequel je me souviens avoir lu les notes de mise à jour, c'est que certaines itérations de la période des années 1990 de ... je veux dire Solaris, mais cela pourrait être faux ... ont offert un serveur pour le protocole de dépôt AppleTalk (AFP), qui était l'équivalent de NFS pour MacOS classique. . Le problème était que, sur MacOS classique, vous êtes parfaitement autorisé à insérer /un composant de chemin d'accès; le séparateur de répertoire est à la :place. Le serveur AFP était censé faire l'équivalent moral detr :/ /: mappage des chemins d'accès soumis par les clients sur des fichiers sur son disque, mais ils ont raté quelques chemins de code, et parce que le serveur a été implémenté à l'intérieur du noyau, il pourrait en fait écrire des entrées de répertoire incorrectes.

(Voir la FAQ 2.2 de comp.unix , la sous-section commençant par "Que faire si le nom de fichier contient un '/'?", Pour une version plus longue de ce qui précède.)

— zwol
source