J'ai reformulé un peu vos questions, pour des raisons qui devraient apparaître évidentes lorsque vous les lisez dans l'ordre.
1. Est-il possible de configurer le système de fichiers Linux en utilisant un codage de caractères fixe pour stocker les noms de fichiers quel que soit l'environnement LANG/LC_ALL ?
Non, ce n'est pas possible :comme vous le mentionnez dans votre question, un nom de fichier UNIX n'est qu'une séquence d'octets ; le noyau ne sait rien de l'encodage, qui est entièrement un concept d'espace utilisateur (c'est-à-dire au niveau de l'application).
En d'autres termes, le noyau ne sait rien de LANG /LC_* , il ne peut donc pas être traduit.
2. Est-il possible de laisser différents noms de fichiers se référer au même fichier ?
Vous pouvez avoir plusieurs entrées de répertoire faisant référence au même fichier ; vous pouvez le faire via des liens physiques ou des liens symboliques.
Sachez cependant que les noms de fichiers qui ne sont pas valides dans l'encodage actuel (par exemple, votre chaîne de caractères GBK lorsque vous travaillez dans une locale UTF-8) s'afficheront mal, voire pas du tout.
3. Est-il possible de patcher le noyau pour traduire l'encodage des caractères entre le système de fichiers et l'environnement actuel ?
Vous ne pouvez pas patcher le noyau pour ce faire (voir 1.), mais vous pouvez - en théorie - patcher la bibliothèque C (par exemple, glibc) pour effectuer cette traduction, et toujours convertir les noms de fichiers en UTF-8 lorsqu'il appelle le noyau, et les reconvertir dans la version actuelle encodage lorsqu'il lit un nom de fichier depuis le noyau.
Une approche plus simple pourrait consister à écrire un système de fichiers superposé avec FUSE, qui redirige simplement toute demande de système de fichiers vers un autre emplacement après avoir converti le nom de fichier vers/depuis UTF-8. Idéalement, vous pouvez monter ce système de fichiers dans ~/trans , et lorsqu'un accès est fait à ~/trans/a/GBK/encoded/path alors le système de fichiers FUSE accède vraiment à /a/UTF-8/encoded/path .
Cependant, le problème avec ces approches est le suivant :que faites-vous des fichiers qui existent déjà sur votre système de fichiers et qui ne sont pas encodés en UTF-8 ? Vous ne pouvez pas simplement les passer non traduits, car alors vous ne savez pas comment les convertir ; vous ne pouvez pas les modifier en traduisant des séquences de caractères invalides en ? car cela pourrait créer des conflits...