Linux? - Page 107

Normaliser les noms fichiers directement dans le FS n'est pas forcément faire les choses correctement. Il y a, il me semble, certains caractères qui seront toujours normalisés vers un autre (peu importe la normalisation choisie) bien que différents graphiquement. En normalisant les noms de fichier tu peux dans certains cas perdre de l'information. (Tu en perds dans tous les cas, mais l'information "dénormalisée" n'est pas toujours (rarement, en fait) une information utile)
Ce qui compte, c'est que tu retrouves ton fichier en cherchant une chaîne équivalente à son nom. Mais dans ce cas, tu dois normaliser chaque nom de fichier avant d'effectuer la comparaison. Il me semble que c'est "la" bonne façon de faire, mais c'est moins efficace.

Sally (./3170) :
Moui, enfin OSX a parfois un comportement chelou avec sa gestion des fichiers, par exemple si tu crées une archive tar sans avoir préalablement défini une variable d'environnement obscure (il s'agit donc d'un comportement par défaut) il la remplit de fichiers vides avec des noms commençant par ._, c'est vachement pratique . Donc ouais ok ils gèrent bien les noms unicode mais ils ont d'autres progrès à faire sur la gestion des fichiers...

Sauf qu'il y a une raison a ce comportement, et il est souhaitable qu'il le fasse par défaut

Sinon la vrai solution c'est ce que j'ai donné en ./3163

FS -> codage forcé dans un mode précis
VFS -> prends n'importe quelle locale userland en entrée et sortie et fait les conversion qui vont bien entre le FS et le userland.

libicu est fait pour ça!

flanker (./3169) :
Avec mod_xsendfile, tu mets le chemin absolu dans l'en-tête HTTP, et c'est Apache qui lit le fichier (donc plus rapide qu'en PHP/Python/..., consomme moins de mémoire, etc.)

Vi, et en plus il gère la reprise du téléchargement, l'envoi d'un 304 Not modified à la place du fichier quand c'est approprié, et quelques autres trucs qui sont fastidieux à implémenter correctement.

Et sinon, si t'as des doutes sur tes noms de fichiers, j'ai retrouvé le nom de l'outil, c'est convmv

Godzil (./3182) :
FS -> codage forcé dans un mode précis
VFS -> prends n'importe quelle locale userland en entrée et sortie et fait les conversion qui vont bien entre le FS et le userland.
libicu est fait pour ça!

On ne peut pas utiliser des bibliothèques dans le noyau, à moins de ne les dupliquer et de les compiler et linker statiquement dans le noyau, ce qui est très indésirable dans le cas d'une bibliothèque énorme comme libicu.

Le Unicode n'a rien à faire dans le noyau!

Brunni (./3171) :
Après il me semble que le filesystem lui-même devrait choisir un encodage et s'y tenir, en garantissant qu'un fichier, qu'il soit désigné par "chié" ou "chi´e" soit accessible de la même manière.

Tout le monde n'est pas d'accord avec ça. Amha le FS n'est qu'un exécutant, pourquoi devrait-il s'inquiéter des locales utilisées 50 niveaux plus haut que lui ? Je saisis pas pourquoi pour beaucoup ici, c'est si évident.

spectras (./3183) :
Et sinon, si t'as des doutes sur tes noms de fichiers, j'ai retrouvé le nom de l'outil, c'est convmv

Déjà mentionné par moi dans mon ./3120.

Godzil (./3182) :
Sauf qu'il y a une raison a ce comportement

Je n'ai pas dit le contraire, encore heureux . Mais c'est un peu un hack foireux quand même

Godzil (./3182) :
il est souhaitable qu'il le fasse par défaut

ça, ça dépend des utilisations...

Sally (./3187) :

Godzil (./3182) :
Sauf qu'il y a une raison a ce comportement

Je n'ai pas dit le contraire, encore heureux . Mais c'est un peu un hack foireux quand même

Oui, j'ai déjà trituré des paquets mac, c'est le grand bordel dedans Evidemment qu'il y a des raisons, comme pour le fait d'écrire un nom de fichier comme-ci ou comme-ça. Mais bon...

J'avoue que ce débat me fait vraiment penser a de l'enculage de mouche, j'ai beaucoup de chose a reprocher à Linux comme à Windows et Mac OS X. Mais la gestion de ce genre de problème ultra rare de nom de fichier, c'est le dernier de mes soucis.

Sally (./3187) :

Godzil (./3182) :
Sauf qu'il y a une raison a ce comportement

Je n'ai pas dit le contraire, encore heureux . Mais c'est un peu un hack foireux quand même

D'accord pour dire que c'est un gros hack tout moche. Par contre, je ne le trouve pas si foireux que ça. Il est moche sous Windows parce qu'on voit les fichiers ._. (qui ne sont pas cachés, même si le fait qu'un fichier commençant par . soit caché est un autre hack tout moche), mais il n'est pas trop embêtant, et il permet de bien simplifier la vie sous OS X.

Le gros problème vient de l'absence de méta-données standards sur les fichiers

Actuellement, on a simplement le nom du fichier, la taille et le contenu.
À partir de là, on essaie de deviner les métadonnées que sont le type MIME (plus ou moins à l'aveuglette à partir de l'extension et des premiers octets), l'encodage est utilisé le cas échéant, une affichette, etc.

Ça serait bien de considérer qu'un fichier, c'est nom (sans extension) + données + métadonnées, et que l'ensemble puisse être transmis à chaque fois.
Techniquement, ça n'a rien de compliqué (et d'ailleurs, il y avait une idée semblable dans de vieilles versions de Mac OS). Malheureusement, ça impliquerait de changer beaucoup de choses dans l'informatique actuelle

./3189 ##modyonlove##

Ah, le problème des metadata des fichiers... Sauf exception, les xattrs sont les parents pauvres dans les FS - quand ils existent.
mmu_man te citerait la gestion des xattrs pour BeFS (BeOS / Haiku), elle fait partie des features proposées par BeOS/BeFS avant la plupart des autres OS/FS.

./3192: Chose fortement inspiré par le HFS/HFS+ ou tout fichier est composé d'au moins deux stream (data/resources) (d'ou le ._ qui stock le stream resource sur un FS autre que HFS) et depuis 10.4/10.5 HFS supporte un nombre arbitraire de stream nommé pour chaque fichiers

ntfs a également des streams.

Lionel Debroux (./3192) :
Ah, le problème des metadata des fichiers... Sauf exception, les xattrs sont les parents pauvres dans les FS - quand ils existent.
mmu_man te citerait la gestion des xattrs pour BeFS (BeOS / Haiku), elle fait partie des features proposées par BeOS/BeFS avant la plupart des autres OS/FS.

Mais dans tous les cas, tu les perds à chaque fois que tu passes par mail ou par internet (voire par clef usb )

désolé mais du coup ça n'a aucune chance d'être utile dans le monde actuel

Si, c'est utilisé par exemple par SELinux pour stocker ses contextes de sécurité. Si tu déplaces le fichier ailleurs, il a de toute façon besoin d'un autre contexte de sécurité en général, donc le problème des partitions qui ne gèrent pas les xattrs et des mails n'en est pas un.

Kevin Kofler (./3184) :
On ne peut pas utiliser des bibliothèques dans le noyau, à moins de ne les dupliquer et de les compiler et linker statiquement dans le noyau, ce qui est très indésirable dans le cas d'une bibliothèque énorme comme libicu.

On le fait déjà avec d'autres trucs. Et puis ça peux passer par du userland pour faire les conversion, avec des méthodes de discutions a la udev/load_firmware.

Kevin Kofler (./3184) :
Le Unicode n'a rien à faire dans le noyau!

Ben sur que si! D'ailleurs le kernel à déjà des choses lié a l'i18n et c'est le plus a même de faire ce genre de choses

Godzil (./3198) :
Et puis ça peux passer par du userland pour faire les conversion, avec des méthodes de discutions a la udev/load_firmware.

Je ne vois pas pourquoi le userland ne devrait pas s'en occuper lui-même, sans embêter le noyau avec ça. C'est quand-même beaucoup plus propre comme solution.

Kevin Kofler (./3184) :
Le Unicode n'a rien à faire dans le noyau!

Ben sur que si! D'ailleurs le kernel à déjà des choses lié a l'i18n et c'est le plus a même de faire ce genre de choses

Je ne suis pas d'accord. Le Unicode a sa place dans la libc ou d'autres bibliothèques système (comme par exemple la libicu), le noyau n'a pas à s'en occuper.

quel est l'intérêt, à part permettre de rajouter tout plein de bugs et d'incompatibilités ?

Ce n'est pas une fonctionnalité qui a sa place dans un noyau tout simplement. Le noyau doit s'occuper de l'essentiel pour gérer le matériel. Gérer les langues et les chaînes de caractères, et donc Unicode, peut être fait parfaitement sans accès privilégié, donc c'est le boulot des bibliothèques utilisateur, pas du noyau. C'est aussi important pour la sécurité: Mettre de la manipulation inutile de chaînes de caractères dans le noyau risque d'introduire des vulnérabilités dans du code qui tourne avec les pleins privilèges!

edit : non rien, en fait

utiliser des wchar dans les noyaux serait totalement et parfaitement inutile pour un système en anglais. Et y'en a quand même pas mal autour de nous.
ce serait sous optimal, en stockage et en données transférées.

si par hasard l'unicode avait sa place dans le noyau, il faudrait que ce soit en utf8 et pas autre chose, ce qui est donc déja le cas.

pour résoudre vos problèmes de normalisation (à la mord moi le noeud il faut bien le dire) il faudrait qu'effectivement il y ait une normalisation unique spécifiée quelque part. Et que tout ce qui fait rentrer des noms de fichiers utilise cette normalisation.

ce que je veux dire, c'est que c'est pas une histoire de gestion de l'unicode, mais bien une histoire de normalisation.

Alors là on peut débattre d'où mettre cette normalisation, personnellement je la verrais plutot dans les fonctions du genre fopen(), pour qu'open() soit une image userspace des appels systèmes sans normalisation.

et pour les stockages de masse...
il faudrait également spécifier correctement leur encodage au niveau du système de fichiers, pour que le FS soit cohérent selon les systèmes qui y accèdent . mais des (non-décisions) ont déja été prises, on ne peut pas imposer à tous les FS d'utiliser UTF-8. Dans ce cas je pense que c'est au driver de FS de se débrouiller; et c'est plus ou moins déja le cas avec FAT, vu qu'on peut donner un encodage à mount.

flanker (./3190) :
même si le fait qu'un fichier commençant par . soit caché est un autre hack tout moche), mais il n'est pas trop embêtant, et il permet de bien simplifier la vie sous OS X.

Pourquoi considérer ça comme un hack, et ne pas le prendre comme une convention ?

flanker (./3190) :
Le gros problème vient de l'absence de méta-données standards sur les fichiers

Folco (./3205) :
Pourquoi considérer ça comme un hack, et ne pas le prendre comme une convention ?

Parce que :
- historiquement, c'est un hack moche (c'était un bug qui a été requalifié en feature, on en a parlé y'a pas longtemps)
- au même titre que les extensions de fichiers, l'attribut "caché" c'est quelque chose qui ne fait pas partie du nom, et qui devrait être stocké sous la forme de métadonnée.

Merci 0^2 ^^

(puis je suis contre le principe des fichiers cachés, surtout quand ce sont des préférences )

oui, il ne sert a rien de cacher ses préférences, on les découvre toujours tôt ou tard

Flanker : Et comment ça se passe si linux écrit sur une partition au format Mac ?

aucune idée ^^