mh si. suivant à quel niveau on se place c'est un problème de ceci ou de cela, ou même un problème de méthode ou d'ergonomie. n'afficher que des icones pour différencier les "types de fichiers" va gêner les defficients visuels, par exemple. si on classifie par couleur on n'aura pas les mêmes réactions chez l'utilisateur le jour ou la nuit. ou suivant la couleur de fond de l'application. déjà que vi dans un terminal peut vite devenir pénible avec les mauvaises couleurs... (et on passera sous silence les conséquences de trier par couleur avec des valeurs chromatiques très proches)
bah je considère les quelques lettres après le . à la fois comme des données et des métadonnées. les protocoles réseaux me transfèrent ça très très bien. quel est le problème, déjà ?
en fait après les extensions on devrait aussi supprimer les noms de fichiers et ne plus garder que les inodes : ces meta-donnees n'ont rien à faire dans le nom de fichier, leur place c'est le système de fichiers ! wait...
c'est comme se plaindre que libmagic "n'est pas suffisament fiable" parce qu'il peine sur des données aléatoires ou sans header spécifique. il se trouve que personne n'utilise directement libmagic mais la commande file et ses équivallents intégrés aux navigateurs :
The file command identifies the type of a file using, among other tests, a test for whether the file begins with a certain magic number.
libmagic reconnait les archives au format Zip comme des archives au format Zip et pas OpenOffice, (Java) JAR ni autres documents composites compressés ? c'est *NORMAL*, son boulot s'arrete là. c'est une librairie. c'est à l'application au dessus à gratouiller pour voir si un xml compressé ne serait pas par hasard du SVG ou autre, éventuellement en appellant d'autres librairies spécialisées
et ça ne m'étonnerait pas qu'un jour l'option -z mentionnée plus bas se retrouve activée par défaut
sur HP-28, 48 et autres 49, toutes les entités manipulables par l'utilisateur (entiers, réels, chaines de caractères, graphiques...) avaient une entête de 5 quartets indiquant le type : il y en avait environ 25. c'était bien, mais pas vraiment extensible : ces valeurs étaient en fait des pointeurs vers la rom, et puis surtout, dès que deux utilisateurs auraient voulu s'échanger des objets pas-de-base, il aurait fallu se concerter pour utiliser les mêmes valeurs d'entête... et un consortium pour gérer tout ça : ils avaient réussi à avoir des conflits de numéro pour les librairies... (pour donner un ordre d'idées, c'est du même tonneau qu'un même numéro de port utilisé par plusieurs applications réseau)
[^] # Re: Sécurité
Posté par Gniarf . En réponse au journal En finir avec libmagic. Évalué à 2.
bah je considère les quelques lettres après le . à la fois comme des données et des métadonnées. les protocoles réseaux me transfèrent ça très très bien. quel est le problème, déjà ?
en fait après les extensions on devrait aussi supprimer les noms de fichiers et ne plus garder que les inodes : ces meta-donnees n'ont rien à faire dans le nom de fichier, leur place c'est le système de fichiers ! wait...
c'est comme se plaindre que libmagic "n'est pas suffisament fiable" parce qu'il peine sur des données aléatoires ou sans header spécifique. il se trouve que personne n'utilise directement libmagic mais la commande file et ses équivallents intégrés aux navigateurs :
The file command identifies the type of a file using, among other tests, a test for whether the file begins with a certain magic number.
libmagic reconnait les archives au format Zip comme des archives au format Zip et pas OpenOffice, (Java) JAR ni autres documents composites compressés ? c'est *NORMAL*, son boulot s'arrete là. c'est une librairie. c'est à l'application au dessus à gratouiller pour voir si un xml compressé ne serait pas par hasard du SVG ou autre, éventuellement en appellant d'autres librairies spécialisées
et ça ne m'étonnerait pas qu'un jour l'option -z mentionnée plus bas se retrouve activée par défaut
sur HP-28, 48 et autres 49, toutes les entités manipulables par l'utilisateur (entiers, réels, chaines de caractères, graphiques...) avaient une entête de 5 quartets indiquant le type : il y en avait environ 25. c'était bien, mais pas vraiment extensible : ces valeurs étaient en fait des pointeurs vers la rom, et puis surtout, dès que deux utilisateurs auraient voulu s'échanger des objets pas-de-base, il aurait fallu se concerter pour utiliser les mêmes valeurs d'entête... et un consortium pour gérer tout ça : ils avaient réussi à avoir des conflits de numéro pour les librairies... (pour donner un ordre d'idées, c'est du même tonneau qu'un même numéro de port utilisé par plusieurs applications réseau)