Ou la difficulté de connaître le type d'un fichier
Ce qui existe actuellement
Je ne vais pas parler de Mac OS qui est en avance sur ce point là mais juste regarder ce qui est a présent utilisé sur nos bureaux libres et moins libres comme Windows :
D'abord il y a l'ignoble extension accolée au nom du fichier. L'avantage indéniable de cette solution c'est qu'elle est facile a mettre ne oeuvre et qu'il est facile de modifier l'extension, .doc le type, du fichier. Mais cela pose aussi plusieurs problèmes :
- Ce n'est pas très élégant. Pensez ce que vous voulez mais pour moi un nom de fichier ne doit pas contenir d'autres méta-données. Que pensez vous de stoker en plus la date de modification dans le nom du fichier ?
- Ce n'est pas assez pour identifier un type de fichier, surtout si on se limite à l'extension à 3 lettres.
- Il est trop facile de modifier l'extension par mégarde sans qu'on le veuille. Pour des utilisateurs novices cela peut poser un problème évident.
Une autre solution qui évite pas mal ces problèmes c'est le nombre magique (magic number) au début du fichier. C'est très bien mais :
- Certains formats de fichiers (comme le format texte) ne possèdent pas cette information.
- Certains formats de fichiers peuvent être détectés comme d'un autre format. Par exemple un fichier Open Document est en fait une archive ZIP. Son nombre magique est celui d'une archive ZIP et sera incorrectement vu comme une archive ZIP.
Même si cette solution est meilleure, ce n'est pas encore ça car ses limites nous force a continuer d'utiliser les extensions de fichiers.
Mais de meilleures solutions existent
Ah ? Quelles sont-elles ?
Mac OS qui depuis bien longtemps déjà nous fournit une interface utilisateur conviviale avait utilisé le système OSType. Cette information détermine le type de fichier de manière cependant limitée. C'est pour cela qu'elle a été depuis abandonnée.
On connaît aussi très bien le type MIME souvent associé aux e-mails et de la forme type/subtype (comme text/plain). Cette méthode est l'une des meilleures et aussi très utilisée sur Internet. Mais cependant a de petits inconvénients comme le manque de standardisation des types mime (pour les types qui ne sont pas enregistrés auprès de l'IANA)
Apple comprenant les critiques de ses utilisateurs concernant l'utilisation des extensions a décidé (depuis Mac OS 10.3) d'utiliser un système alternatif : UTI (Uniform Type Identifier).
Ce système a l'avantage de limiter les collisions avec l'utilisation de la notation DNS inversée. Ainsi par exemple une image PNG aura le type public.png et une image PICT aura le type com.apple. Ce
Chaque type peut aussi hériter d'un ou plusieurs autres types permettant ainsi une grande flexibilité (ce que ne propose pas le type MIME). Ainsi un fichier JAR de type com.sun.java-archive hérite entre autre de public.archive.
Mais pourquoi ne les utilise-t-on pas ?
Le principal problème c'est que l'information sur le type du fichier doit aller dans les méta-données et que traditionnellement, sauf pour quelques systèmes, le type du fichier n'y est pas inclus. Ce plus cela implique de fournir le type de fichier lors des transferts de fichiers. Ce problème est en partie résolu par l'utilisation extensive du type MIME dans beaucoup de protocoles.
Cependant, la plupart des systèmes de fichiers actuels supportent l'utilisation d'attributs étendus. Alors que reste-t-il pour nous empêcher ?
Même si cela est possible, cela reste a standardiser pour que cela soit utilisable. Pour le moment les bureaux libres ne considèrent pas ce problème. GNOME et KDE (pour ne prendre que les deux les plus considérés) utilisent les nombres magiques doublés de l'extension du fichier pour lever les ambiguïtés. Mais cela n'est pas toujours pratique.
Ainsi par exemple, si on cherche à ouvrir un fichier avec nautilus, et que ce fichier a un nombre magique qui contredit l'extension, une boîte de dialogue nous informe qu'on ne peux ouvrir le fichier (pour des raisons de sécurité). Ces cas peuvent facilement se produire lorsque par exemple un format de fichier consiste en un des données gzippées.
Qu peut-on faire ?
Je ne sais pas, j'invite tout le monde qui a de bonnes idées a les proposer. L'idéal serait que freedesktop.org nous propose un format standard (de préférence utilisant des standards existants) qu'il soit possible d'inclure dans les attributs étendus, et qu'il soit développé des outils en ligne de commande (et aussi pour nautilus, konqueror, thunar, rox, ...) pour facilement voir et modifier cette information.
Mais je n'ai malheureusement rien vu de tel.
Et vous, qu'en pensez-vous ?
liens
http://www.gnome.org/learn/users-guide/latest/nautilus-open-(...)
http://developers.sun.com/solaris/articles/integrating_gnome(...)
http://developer.kde.org/documentation/library/kdeqt/kde3arc(...)
http://en.wikipedia.org/wiki/File_format#Identifying_the_typ(...)
http://en.wikipedia.org/wiki/OSType
http://en.wikipedia.org/wiki/Type_code
http://en.wikipedia.org/wiki/Uniform_Type_Identifier
Journal En finir avec libmagic
9
juin
2007
# Foutu d'avance...
Posté par Pinaraf . Évalué à 6.
Mais vu l'état du "marché" c'est foutu d'avance. En effet, un monstre possède plus de 95% du marché et toute solution qui ne s'intègre pas ou mal sur ce monstre et ses standards est mal barrée.
Certes après on peut se dire "ouais nos bureaux utilisent pas les extensions", mais on devra les garder pour windows. Compte pas sur les systèmes de fichiers : le FAT pour les clés USB et cartes mémoires c'est pas demain que ça s'arrêtera...
Puis si on se faisait un standard joli tout plein, si lors de la sortie de vista+2 microsoft corrigeait ce problème ça serait sûrement avec son propre format incompatible et un bordel immonde à gérer pour nous...
Welcome to the real world.
[^] # Re: Foutu d'avance...
Posté par Dup (site web personnel) . Évalué à 3.
En allant plus loin cela pourrait même être un bon argument d'utilisation d'un OS libre.
[^] # Re: Foutu d'avance...
Posté par Nicolas Schoonbroodt . Évalué à 8.
[^] # Re: Foutu d'avance...
Posté par Pinaraf . Évalué à 2.
En gros le navigateur de fichier doit rester compatible avec l'ancienne méthode, l'ancienne ancienne méthode tout en implémentant une nouvelle méthode. Sympatique tout ce micmac...
[^] # Re: Foutu d'avance...
Posté par moramarth . Évalué à 4.
Alors comment font-ils chez Apple ? On n'a pas les moyens d'innover envers et contre Microsoft chez les libristes ?
[^] # Re: Foutu d'avance...
Posté par moramarth . Évalué à 8.
Quand je transfert de la musique AAC d'iTunes Store, la réencode en ogg, toujours sous Panther, puis l'envoie sur ma petite merde de Samsung YP-T7FX, qui ne fonctionne qu'avec UMS et fat compatible, mon petit baladeur parvient malgré tout à ne pas le confondre avec les mp3 (qu'il lit aussi) et ça marche. ET ÇA MARCHE.
Effectivement, ce n'est pas toujours des solutions très propres, chez Apple, par exemple, un iPod profitant d'un bien plus moderne HFS+ plutôt que de FAT32, c'est possible. Utiliser du FAT32 et avoir ses musiques du Windows ou du Mac OS lues, c'est possible aussi. C'est juste que le HFS+ enferme dans la tour d'ivoire de tout le monde - Windows, c'est-à-dire -10% du marché. Mais bon à part ce détail, c'est transparent. Les détails : http://docs.info.apple.com/article.html?artnum=61672-fr
Donc, Apple se débrouille, et prend même des risques pour forcer l'innovation, quitte à mettre en danger l'expérience de l'utilisateur. Et on me dit : Non, le libre peut pas, pas réaliste !
Ce sont les libristes qui (d'ordinaire) ont une innovation bouillonnante, parfois un peu brouillon, mais qui à force de chercher finit par trouver et bien plus tôt que les autres. Quel monde a en premier popularisé les widgets/desklets (oups, un indice), les bureaux virtuels, Unix, une gestion fine de l'installation de logiciel, et bien d'autre ? On a déjà la réputation d'être un système pour casse-cou, si en plus on n'en prend pas les avantages…
Non, vraiment, je ne peux pas cautionner ton propos, Pinaraf, même avec ton +6.
[^] # Re: Foutu d'avance...
Posté par Pinaraf . Évalué à 1.
Maintenant, copie toto sur ta clé USB. Vérifie bien que toto n'a pas d'extension.
Ensuite, ouvre ta clé USB sur windows. Bon amusement pour ouvrir toto.
Autre solution : envoie toto dans une archive par mail.
Autre solution : envoie toto sur un serveur web.
Autre solution : balance toto sur un partage réseau...
[^] # Re: Foutu d'avance...
Posté par moramarth . Évalué à 5.
Non, mon propos était qu'il faut parfois oser, pour briser le carcan actuel et aller de l'avant. L'innovation, c'est aussi l'audace. Et pourquoi le libre devrait être un monde frileux, en retrait dans le monde de l'innovation ?
Enfin, dernière solution, peut-être la plus simple : cacher les extensions et les laisser néanmoins, pour la compatibilité. Les utilisateurs de technologie récentes ne se rendant alors plus compte que le nom du fichier et pollué par les extensions, et les utilisateurs de technologies anté-diluviennes, n'ayant qu'à assumer ?
J'ai remarqué dans mon Nautilus, que la première fois qu'il affiche un fichier ogg/theora, dans un dossier, il met beaucoup de temps avant de donner la bonne icône. Après c'est instantané. Ne scanne-t-il pas le fichier pour déterminer son type et l'inscrire en métadonnée? Alors on peut récupérer des fichiers d'autres types qui n'ont que des extensions et aussi pouvoir les préciser en reconstruisant la métadonnée idoine manquante. Donc, pousser au maximum pour avoir quelque chose de moderne.
Ensuite, dorénavant, dans le monde du libre, on peut lire et écrire du NTFS, autrement dit, la relégation aux oubliettes de fat n'est qu'une question de temps. Les FAT restant gêneront avec le petit temps de réécriture de la métadonnée, mais ça se raréfiera. C'est un coût d'expérience utilisateur minime, et qui décroîtra avec le temps.
J'ai longtemps été extrêmement libriste, mais à force d'avoir du pragmatisme pour faire fonctionner mon environnement, on finit par avoir un monde libre façonné en partie significative par les contraintes extérieures. C'est dommage. Et du coup Windows, Mac OS, Ubuntu, GNewSense, ce n'est plus qu'une question d'opinion personnelle, différents degrés de pragmatisme.
Ne vaudrait-il mieux pas essayer de forcer un peu le cours des choses plutôt que d'affirmer qu'on ne peut rien faire?
C'est ça mon propos, pas que Mac OS fonctionne systématiquement ou non lors d'un transfert de fichier vers Windows via une clé USB en FAT, pour reprendre ton objection.
[^] # Re: Foutu d'avance...
Posté par Pinaraf . Évalué à 5.
Ensuite, le NTFS... C'est bien beau de dire qu'on peut écrire dessus sous Linux. Mais y'a pas que Linux dans la vie. Y'a aussi Mac OS X qui jusqu'à peu n'avait pas encore de pilote NTFS il me semble (avec le port de FUSE c'est peut être possible)
Y'a aussi et surtout les OS embarqués des baladeurs et appareils photos : ça m'étonnerait qu'ils puissent se permettre l'utilisation du NTFS. Sans oublier les dangers liés aux brevets...
Mais j'ai pas d'inquiétude, KDE 4 et le projet Nepomuk (en cours de changement de nom) devraient bien utiliser les meta données (ça se fera progressivement par contre, au fur et à mesure des versions de KDE4...) Et les autres bureaux, ils font ce qu'ils veulent.
[^] # Re: Foutu d'avance...
Posté par moramarth . Évalué à 2.
Pourquoi ? Voilà un système où l'utilisateur n'a jamais à modifier l'extension pour modifier le format, ni à le lire pour gérer le fichier : https://linuxfr.org/~mildred/24648.html#840225
Si un utilisateur fait cette connerie sur un SE concurrent et sans le système du lien, alors on s'en fout : lors de l'importation, ton système corrigera le fichier, après scannage, comme je l'ai déjà expliqué au-dessus.
C'est pas une belle vision ça :¬) ? Comment ça -10 ?
# Ah l'heritage du DOS
Posté par Dup (site web personnel) . Évalué à 4.
Donc la solution la plus alléchante serait effectivement d'utiliser les attributs étendus du système de fichier avec possible perte de l'information lors d'une copie vers un autre FS ?
Bref libmagic nous aide bien en attendant d'utiliser ces fameux attributs étendus, et je pense que cela se démocratisera lorsque Gnome et KDE intégreront la gestion de ces attributs.
D'ailleurs je pense que je vais me renseigner comment peut-on gérer ces attributs, car j'avoue n'avoir jamais tenté de jouer avec.
[^] # Re: Ah l'heritage du DOS
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
C'est qui l'utilisateur lambda ?
Parce que ça fait plusieurs années que l'utilisateur de base ne voit plus les extensions de fichiers sous Windows...
Et que sous Linux il ne sait pas a quoi ça sert, puisque quand il les supprime ça marche quand même...
[^] # Re: Ah l'heritage du DOS
Posté par B16F4RV4RD1N . Évalué à 8.
Pour ma part j'apprécie le fait d'avoir des extensions de fichiers, car je ne crois pas que l'on puisse identifier plus rapidement un type de fichier qu'avec un coup d'oeil. Et si sous Gnome ou KDE le type peut être identifié avec une icône, ou avec une bulle d'aide ou je ne sais quoi d'autre, qu'en est-il en console ? Je trouve également pratique de pouvoir filtrer avec un ls *.png par exemple pour trouver tous les fichiers de ce type en ligne de commande. (Quand à la date, pour certains fichiers je trouve également pratique de l'inclure dans le nom du fichier). Et même en faisant abstraction des icônes, je trouve l'extension de fichier plus parlante.
Si je ne m'abuse, 3 lettres permettent de composer 17576 types d'extensions différentes...
De plus dans konqueror, si on veut renommer un fichier, l'extension n'est pas sélectionnée par défaut, cela limite la casse.
D'ailleurs avec le type de fichier inclus dedans, et sans extension, cela risque toujours de poser problème. Un client sous MAC m'envoie un fichier sans extension, je regarde le type avec file, mais pour je ne sais quelle raison c'était juste marqué qque chose comme "data", sans rien de plus. (pour info c'était un document word en fait...)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Ah l'heritage du DOS
Posté par fmaz fmaz . Évalué à 2.
On peut décider d'interdire les # dans les noms de fichiers et les utiliser comme séparateur de meta-données
On pourrait donc faire ls *#png#date=today#size<10ko
Bref. De toute façon, il faut abandonner les systèmes de fichiers hiérarchiques.
[^] # Re: Ah l'heritage du DOS
Posté par Anonyme . Évalué à 7.
Pour quel autre architecture ?
[^] # Re: Ah l'heritage du DOS
Posté par fmaz fmaz . Évalué à 8.
Les répertoires ne sont que des requêtes sur une BDD.
ls /pdf/!author:jlapin/création<1 janvier 2006
donnerait tous les pdf dont jlapin n'est pas l'auteur et dont la date de création est avant le 1er janvier 2006. L'intérêt du point de vues répertoires, c'est qu'on peut facilement procéder par affinage successifs.
Comme certaines requêtes sont fréquentes, on pourrait définir des vues.
/home, serait la vue correspondant à la requête sur tous les fichiers ayant l'étiquette 'home'.
/home/jlapin serait un raffinage de la vue précédente.
Elle contiendrait tous les fichiers ayant les étiquettes 'home' et 'jlapin'
Pour éviter le bordel, dans /home, comme il y a jlapin, on vire tous les fichiers qui apparaissent dans jlapin.
On peut aussi avoir une vue /mail/lapinette&(non patron).
Ensuite, par dessus ce genre de choses, on peut imaginer un moteur d'étiquetage (beagle et autre) qui ajouterait de façon dynamique des étiquettes => paf les répertoires sur des filtres bayesiens.
Ainsi, on virerait toute la logique de base de données des mailers, et autres gestionnaires de tous poils (musique, vidéo, photo, timbres...). Tous les utilitaires qui travaillent directement avec le système de fichier pourraient avoir accès à ce genre de fonctionnalités. Bref.
Un système allant dans ce sens est BFS [1]. Mais le système écrit par Yoann Padioleau dans sa thèse [2], bien que pas complètement mature, c'est avant tout un travail de recherche, va beaucoup plus loin que BFS. L'introduction de sa thèse est vraiment très intéressante et l'état de l'art qu'il dresse est vraiment bien.
En fait, je pense que la logique BDD peut se rajouter sans trop de problèmes sur un système de fichier classique. C'est d'ailleurs comme cela que certains systèmes de fichiers ont commencés.
Bref.
[1] http://fr.wikipedia.org/wiki/BFS
[2] http://www.irisa.fr/centredoc/publis/theses/2005/irisapublic(...)
[^] # Re: Ah l'heritage du DOS
Posté par Ontologia (site web personnel) . Évalué à 2.
Rappelons qu'un secteur de boot, sur un pc, se contente de copier le contenu de quelques clusters du disque, dont le numéro est connu, afin d'exécuter le contenu une fois copié en mémoire.
Ensuite, il faut lire le fichier contenant le noyau.
Pour lancer une telle fs, il va falloir installer un bonne couche de filesystem avant de pouvoir lire quoique ce soit.
Après, est-ce que l'on garde une structure (idéale) du genre :
*system
** Boot
*** $BOOT
**** Binaries
**** Settings
**** Ressources
** Kernel
*** $KERNEL
**** Binaries
**** Settings
**** Ressources
** Devices
*** $DEVICE
**** Binaries
**** Settings
**** Ressources
** Library
*** Objects
**** Binaries
**** MetaDatas
*Programs
** $PROGRAM
*** Binaries
**** Library
**** Masters Objects
**** ...
*** Settings
*** Ressources
*Users
** $USER
*** System ~> /system
*** Programs ~> /programs
*** Ressources
**** Desktop
**** Documents
**** Videos
**** ...
Est-ce que cette structure doit être une vue, adressable via un ensemble de requêtes sur le fs ?.. Où une structure fixe qui dénormaliserait ce genre d'approche ?
Autre chose, une organisation pareil implique que l'on range les répertoires avec des types de fichiers plus ou moins prédéfinis, quelle approche privilégier, une structuration fixe de l'arborescence, afin de s'assurer de toujours retrouver ce que l'on veut au même endroit, en particulier tout ce qui a trait à l'OS, ou privilégie t-on une approche où tout va être structuré de manière plus "floue" en se disant que le système de requête pourvoiera ?..
Bref, comme tu le disais à la fin, on tente une approche de transition, ou on implémente (imagine que l'on fasse ça avec un nouvel OS, Hurd par exemple) directement le concept dans son intégralité et dans une totale cohérence ?
Bon je -> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ah l'heritage du DOS
Posté par fmaz fmaz . Évalué à 3.
Bon, je recommence.
Avec un FS, on peut accéder à un fichier de deux façons: avec l'inode, avec le chemin.
Ce que je propose, c'est changer la sémantique du chemin, pas de changer l'organisation des données sur le disque. Pour le boot initial, cela ne poserai donc pas de problèmes.
Par ailleurs, si on n'utilise que des chemins qui correspondent à des requêtes conjonctives, si chaque étiquette correspond à une vue et si on ne crée pas plusieurs fichiers avec le même nom et les mêmes étiquettes, on se retrouve avec exactement le comportement d'un fs classique. À moins d'essayer de faire des choses bizarre, un script ou un programme n'aurait aucun moyen de faire la différence.
L'aspect transition pourrait donc se faire en:
- changeant le fs ;
- puis modifier le reste pour utiliser les fonctionnalités offertes.
Maintenant, pour l'aspect lourdeur, si on a gardé des fs hiérarchiques et pas des bdd, c'est, je pense initialement pour une question de lourdeur puis par habitude. Il y a 20 ans, les ordinateurs ne pouvaient pas se permettre d'incorporer dans un fs, une base de donnée. Maintenant, quand on voit ce que font zfs ou reiser 4, je ne pense pas qu'une base de donnée pose des problèmes insurmontables.
[^] # Re: Ah l'heritage du DOS
Posté par inico (site web personnel) . Évalué à 1.
Une database pour les données s'est bien mais pour les binaires d'un OS, ca ne le fait pas.
[^] # Re: Ah l'heritage du DOS
Posté par B16F4RV4RD1N . Évalué à 5.
possible, mais cela ne résout pas les autres problèmes évoqués, ainsi que l'impossibilité d'avoir les mêmes noms de fichier dans un même répertoire (voir autre commentaire plus bas). Pour distinguer les fichiers avec le même nom mais de types différents, autant mettre une extension, c'est le plus rapide et le plus pratique.
ben je n'espère pas. Je ne vois pas en quoi le fait de bien classer ses documents en divers sous-dossier pose problème. Éventuellement il est possible d'ajouter une sur-couche de "dossiers virtuels" ou de "tags" pour avoir plus de précisions, mais cela n'enlèvera pas l'intérêt d'avoir un classement hiérarchique.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Ah l'heritage du DOS
Posté par z a . Évalué à 1.
[^] # Re: Ah l'heritage du DOS
Posté par Mildred (site web personnel) . Évalué à 4.
[^] # Re: Ah l'heritage du DOS
Posté par B16F4RV4RD1N . Évalué à 9.
et cela marche dans quel contexte ? Parce que par exemple avec konqueror, si je retirer une extension à un fichier, il ne sait plus avec quoi l'ouvrir, et qu'il utilise justement l'extension pour faire des motifs de fichiers.
J'ajouterais également que je vois un autre gros avantage aux extensions de fichiers : cela permet d'avoir un fichier de travail et ses diverses variations dans le même dossier.
Par exemple :
contes_du_Japon.t2t (si quelqu'un collecte des contes japonais, et utilise text2tags pour les noter)
contes_du_Japon.html (exportation en html depuis le format txt2tags pour le site internet, hé oui, on peut également avoir des extensions avec plus que 3 lettres, désolé pour la compatibilité dos)
contes_du_Japon.tex (exportation en latex, toujours depuis txt2tags, pour générer ensuite un fichier pdf téléchargeable)
contes_du_Japon.pdf (le fichier en question)
contes_du_Japon.png (un logo pour illustrer le document)
contes_du_Japon.svg (un organigramme sous inkscape)
contes_du_Japon.old (une version temporaire)
contes_du_Japon.tgz (la sauvegarde en cours des divers documents)
on pourra toujours dire qu'il est possible de nommer différemment les fichiers, ou alors d'avoir contes_du_Japon_tex, contes_du_Japon_pdf etc, mais cela revient au même qu'une extension...
De plus pour tous les formats ascii (format musical abc, txt simple, headers .h, script, code source de façon générale), cela permet de savoir directement comment traiter ces fichiers...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Ah l'heritage du DOS
Posté par moramarth . Évalué à 10.
On peut mettre des lettres et des chiffres, donc (26+10)^3= 46 656 possibilités, au lieu de 17 576. Mais même suffisantes, correspondront-elles toutes au nom du format qu'elles représentent ? Ou serait-ce encore plus ésotérique avec le temps ?
Le coup d'½il sur l'extension plus parlante qui dit tout, c'est de la blague : combien d'utilisateurs trouvent cryptique la marée de .htm, .html, .mpeg, .jpeg, .mpg, .jpg, .png, .gif, .tif, .tondu, sans compter les conteneurs ! .avi (qui marche), .avi (mais qui marche pas, parce que ce n'est pas les mêmes codecs requis), .mov (idem), .ogg (idem), etc (idem)…
Tu dis que l'extension est plus parlante, mais c'est parce que tu es un geek qui connait beaucoup de format de fichiers. Mets-toi dans la tête de quelqu'un qui a à peine intégré cette notion…
La solution, c'est laisser les extensions de fichiers mais les cacher dans l'interface graphique. On peut raisonnablement penser qu'un utilisateur qui a le courage de s'affronter avec la console peut s'affronter avec les extensions. L'inverse est en revanche peu probable, surtout dans le grand public.
Et il faut combiner tout ça avec des aperçus. De vrais aperçus. C'est-à-dire dans les icônes :
- L'image réduite pour l'icône de l'image.
- Une partie du texte ou des lignes correspondant à l'aspect général du texte, du moins de sa première page et éventuellement des portions colorées là où il y a des images insérées.
- Un spectrogramme correspondant pour le son (avec peut-être une note de musique, car un spectrogramme, c'est déjà technique, à défaut d'être purement technico-informatique).
- Un des diapositives pour une présentation.
- Une capture du film dans un cadre type pellicule photographique pour un fichier de film (pas forcément la première image, mais une avec quelque chose de contrasté, de coloré : souvent les premières images des fichiers de films sont unicolore.)
- etc.
- Les aperçus précédents à l'intérieur d'une icône dossier, ou un verrou, si on n'y a pas accès, ou un point d'interrogation, si on doit monter un volume pour y accéder.
Quand le curseur passe au dessus d'un fichier temporel, il le lit : les diapos de la présentation défilent, la musique est jouée et le spectrogramme change, le film est joué, on l'entend, les aperçus joués défilent à travers l'icône du dossier, etc…
Si une erreur survient, le système propose à l'utilisateur d'installer le support du format ou du protocole, par exemple lors de l'échec de la construction de l'aperçu, lors de l'échec de sa lecture, demande de mot de passe administrateur lors d'un accès à un dossier protégé, demande de montage d'un volume pour un dossier d'un volume démonté, ou bien d'autre. Si malgré cela, le support n'est pas disponible, on lui dit le nom du format ou protocole problématique, pour qu'il le repère. L'autre cas où on donne le format, c'est lors de la création du fichier, pour qu'il sache s'il utilise un format dont il a entendu qu'il était peu compatible/posait problème à un ami. Dans tous les cas, même si on donne le format ou le protocole, on donne son vrai beau (?) nom complet. Mais JAMAIS d'extension cryptique en trois lettres ou chiffres. Beurk !
Plutôt que de s'avancer vers ça, lentement, sans vision, comme aujourd'hui, il faudrait qu'on s'en occupe sérieusement une bonne fois pour toutes.
Je sais, je sais, je n'ai qu'à rédiger une spec, un ticket d'une wishlist, ou autre. Mais je crains que ce soit trop ambitieux et irréalisable (aperçu de présentations en diapos par exemple), que ce soit trop de travail et que j'emmerde les développeurs à lire des raffinements qui sont bien moins urgents que d'autres projets, que je passe pour encore un utilisateur qui code jamais mais qui demande à être servi comme un roi de plus, etc…
Comme je ne veux pas non plus me défiler je propose un compromis :
Si j'arrive à +10, je rédige le ticket. Si vous pensez que c'est une man½uvre pour avoir un +10, rédigez une réponse m'encourageant clairement à rédiger le ticket, ou plussez-la, si elle existe déjà. Si l'addition des deux notes atteint 10, je rédige le ticket aussi.
[^] # Re: Ah l'heritage du DOS
Posté par B16F4RV4RD1N . Évalué à 2.
comme sous windows, ou sous windows CE. C'est tellement pas pratique que l'on se retrouve parfois avec des fichiers qui ont le même nom mais qui sont différents. Je n'aime pas vraiment.
Mais sinon on peut laisser cela à Gnome, pourquoi pas ? ;)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ah l'heritage du DOS
Posté par WH (site web personnel) . Évalué à 5.
http://en.wikipedia.org/wiki/CP/M#File_system
# de pires solutions existent, mais de meilleures ?
Posté par Antoine . Évalué à 10.
Ah ? Pourtant quand je vois les fichiers toto.c et toto.o, je sais que toto.o est la version code object du code source toto.c. Si le type de fichier était codé dans une méta-donnée séparée, il faudrait donner (de façon arbitraire) un nom différent au fichier source et au fichier objet. Bref, on ne gagnerait rien en élégance et on perdrait en simplicité.
Par ailleurs l'information du type d'un fichier est suffisamment capitale pour justifier d'être visible immédiatement dans son nom. Et une extension de quelques lettres est un codage à la fois lisible et compact (plus compact que des types MIME ou l'horrible système à notation pointée inventée par Apple (apparemment c'est à la mode ce genre de notations pointées DNS-like, comme si n'importe quel concept informatique devait se traduire en pseudo-adresse Internet... ce qui est pour le coup une ânerie conceptuelle probablement due à la paresse)).
Il faut arrêter les préjugés qui consistent à voir toute caractéristique héritée de Microsoft comme une hérésie conceptuelle. Dire que seule la compatibilité Windows justifie l'utilisation d'extensions de fichiers est stupide ; si c'était le cas pourquoi les fichiers .rpm, .deb, etc. porteraient-ils ces extensions alors qu'ils n'ont de sens que sous Linux ? Et pourquoi Unix aurait-il étendu le concept en rendant plausibles les fichiers .tar.gz, .tar.bz2 et autres ?
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par Gniarf . Évalué à 7.
héritée de CPM, en passant...
et comme tu le dis ça existait déjà sous Unix. c'est juste une convention, mais elle est bien trop pratique pour que des génies en culottes courtes viennent me l'enlever.
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par Grégory Soutadé (site web personnel) . Évalué à 2.
Pour la notation DNS-like d'Apple, je dirais que c'ést plutôt inspiré des packages de la prog objet (Java, C#), style qui était déjà présent dans Ada.
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par Gniarf . Évalué à 2.
encore plus rigolo quand une application s'attache à l'extension en 3 lettres et une à celle en 4 lettres. oh et puis souvent c'est une version de mime-type pour l'usage local tel que vu par le gestionnaire de fichiers et une autre pour l'usage "internet" tel que vu par le navigateur \o/
encore plus rigolo quand des génies décident un jour de ne plus préciser "image bmp" "image gif" "image jpeg" mais juste "Image" parce que trop de types ça embrouille l'utilisateur moyen^Wlambda...
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par fmaz fmaz . Évalué à 0.
De toute façon, ils ont des inodes différentes, le système peut donc les identifier. La seule chose, de pouvoir les identifier au niveau de l'utilisateur. Si on reprend la notation meta-données à coup de #, on pourrait très bien faire un
vi toto#c
ls toto#*
qui liste les meta-données des fichiers
...
Bref.
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par Anonyme . Évalué à 10.
Il y a des vrais avantages ?
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par slubman (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par B16F4RV4RD1N . Évalué à 2.
En fait il propose de retirer tout les affichages des extensions (comme sous windows), et sans doute de pouvoir avoir des noms de fichiers identiques dans un même répertoire (il faudra bien permettre cela puisque en plus il est contre le classement hérarchique. Ainsi tout dans le même répertoire, pas d'extensions de fichier, une base de donnée pour gérer cela (et puis si elle explose cela va être sympa, cf. ces utilisateurs heureux de itune ou iphoto qui se retrouvent avec 2 Go de photos ou de musiques dans le même dossier, avec pour seule possibilité de les identifier que d'analyser chaque fichier un à un, pour info j'ai plus de 6500 fichiers sur mon ordinateur qui s'appellent makefile...).
Sans compter que cela devient impossible ou difficile de transporter ses fichiers d'un système à l'autre.
Bref, risqué, difficilement portable et peu logique, moi je n'en veux pas.
Par contre je n'ai rien d'une couche supplémentaire si certains veulent vraiment utiliser beagle par exemple
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par fmaz fmaz . Évalué à 4.
Pour l'aspect « transfert de fichiers », je ne vois pas le problème.
Quand tu envoies un fichier à quelqu'un, tu perds les informations que les droits, sur les différentes dates associées.
Si j'envoie une photo à quelqu'un, je n'ai pas forcément envie que cette personne sache que je lui avais associés les tags 'mon amour', 'noël 2007'.
La seule vraie information importante à transmettre, c'est le type de fichier et libmagic est justement là pour montrer que ce n'est pas si important puisqu'on arrive à deviner le type du fichier sans regarder l'extension.
Tu ne veux pas de mon truc (qui au passage n'est pas mon truc mais celui de beaucoup d'autres) mais tu veux bien d'une couche supplémentaire. Cette couche, comment tu l'implémentes à coup d'appels dans le VFS de gnome ou dans celui de kde ? C'est super pour l'intégration ça, vi ou emacs n'auront pas accès à ces possibilités mais kate ou gedit oui ? Ou alors, tu l'implémentes comme un système de fichier (à coup de fuse) ?
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par fmaz fmaz . Évalué à 4.
Il me semble ridicule qu'un nom de fichier serve à autre chose que donner un nom à un fichier. On ne fait pas apparaître les droits d'accès à un fichier dans le nom du fichier alors quoi doit-on faire apparaître le type du fichier dans le nom ?
Qu'on utilise un ., un : ou un #, ce n'est que de la syntaxe. Je suis d'accord que c'est important mais il me semble qu'on gagnerait vraiment à utiliser une logique de tags en offrant la possibilité d'y accéder depuis la ligne de commande.
Oublions pour un moment l'aspect syntaxe et interdisons l'utilisation d'un . dans le nom d'une étiquette. Ainsi, toto.truc est un fichier toto ayant une étiquette truc.
ls *.owner=jlapin donne tous les fichiers appartenant à jlapin
ls *.c donne tous les fichiers ayant une étiquette c
ls *.c.owner=jlapin donne tous les fichiers appartenant à jlapin et qui ont une étiquette c
Si on réfléchit 30 secondes, la commande find est juste un patch pour pouvoir augmenter les limitations du système de fichier pour accéder aux méta données des fichiers. On ne peut pas écrire
lpr *.pdf.date=today
alors on utilise une commande pour le faire.
Avec une logique de tags + une BDD + une bonne syntaxe, on aurait quelque chose de vraiment puissant.
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par Gniarf . Évalué à 7.
bon allez, deux cas de figure de la vraie vie :
ton copain de bureau, le gros Roger, t'envoie un rapport chez toi
cas 1)
-ca marque je sais pas ouvrir Rapport.rar
-ah il sait pas... ah oui t'es chez toi c'est pas configuré pareil
-et je fais quoi maintenant
-bah euh installe le support du format rar, aptitude install librar
-ah oki c'est pas librar mais je vois ça va aller
cas 2)
-ca marque je sais pas ouvrir Rapport
-ah, et euh c'est tout ?
-oui, c'est tout
-c'est ballot, ça
-et je fais quoi maintenant
-je sais pas lol
-lol
merci de laisser une chance au cas 1, des centaines de millions de personnes te remercieront.
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par fusible . Évalué à 6.
cas 3)
- ça marche pas !
- quoi qui marche pas ?
- ...
- t'as pas un message d'erreur, quelque-chose ?
- béh, il y a une fenêtre avec des trucs bizarres dedans !
- ah... et ?
- ... qu'est-ce que je fais ?
(*pense à toute une série de réponses possibles*)
- écoutes j'ai mon lait sur le feu là ! a+
;)
[^] # Re: de pires solutions existent, mais de meilleures ?
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
> version code object du code source toto.c.
Pire : si je vois toto.c qui contient
int main () {
int class = 42;
return class;
}
je sais que c'est un fichier C syntaxiquement correct.
Si le même fichier s'appelle toto.cpp, je sais que c'est un fichier C++ incorrect. Un machin basé sur le contenu n'aurait jamais pu faire cette distinction.
# Apple me gonfle
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Apple me gonfle avec ses fichiers .DS_STORE et ses fichiers ._Mon_fichier.toto qui mette la configuration personnelle du finder dans l'espace partagé.
Apple me gonfle avec ses solutions réseau qui broadcast en tout sens et qui sont valades pour un réseau familiale.
Apple me gonfle de faire un faux UNIX puisque sans X-Window...
Bref, Apple, c'est bien, mangez-en avec modération.
[^] # Re: Apple me gonfle
Posté par fmaz fmaz . Évalué à 3.
[^] # Re: Apple me gonfle
Posté par z a . Évalué à 1.
[^] # Re: Apple me gonfle
Posté par B16F4RV4RD1N . Évalué à 4.
ok pour les .DS_STORE c'est vrai que c'est lourd (surtout que c'est juste pour aller avec cette grosse bouse de finder)
par contre je ne suis pas d'accord pour le x-window, Apple livre X11, et il est possible d'avoir pas mal de programme unix / linux qui tournent sous mac os x grâce à cela.
Mais on ne peut pas vraiment en vouloir à Apple pour avoir rajouté une surcouche graphique qui permet un affichage bien plus performant et beaucoup plus fluide.
Dommage par contre qu'ils n'aient pas fait profiter de ces avancées technologiques à la communauté...
À la rigueur ce qui m'énerve le plus, ce sont les fan-boys Apple qui vont critiquer les applications issues des Unix (genre OpenOffice), parce que la version X11 c'est "moche" et que cela n'est pas aussi bien intégré à leur mac os x que itunes par exemple.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Apple me gonfle
Posté par Ph Husson (site web personnel) . Évalué à 3.
L'implémentation du composite manager et des toolkits (et encore) oui, mais c'est tout.
[^] # Re: Apple me gonfle
Posté par B16F4RV4RD1N . Évalué à 2.
Quoi qu'il en soit, l'affichage sous Mac OS X est bien plus réactif que X11, il suffit de regarder pour s'en convaincre. Si on déplace une fenêtre, c'est très fluide. Sous X11, c'est saccadé. Même avec les extensions composites, bien que cela c'est un peu mieux, cela reste plus lourd.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Apple me gonfle
Posté par Pinaraf . Évalué à 2.
Mon X réagit instantanément lors d'un clic sur un bouton : il est réactif. Il réagit instantanément aux déplacements des fenêtres. L'affichage de la fenêtre déplacée n'est pas saccadé. Par contre, selon le toolkit de l'application derrière, ça peut apparaître saccadé. Mais c'est qu'une question d'apparence.
[^] # Re: Apple me gonfle
Posté par B16F4RV4RD1N . Évalué à 2.
Sous gnome aussi je crois.
Sous E17 un peu moins.
avec composite, c'est moins saccadé, par contre s'il y a bcp de fenêtre, c'est ralenti, et semble "lourd".
Essaye de comparer avec mac os x, ou vista, c'est objectivement carrément plus agréable.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Apple me gonfle
Posté par Pinaraf . Évalué à 2.
C'est pas la faute de X mais des toolkits et des applications. Teste ça avec que des applis Qt4 par exemple... La fluidité n'a rien à voir avec celle des applis Qt3 grâce au double buffering (et d'autres optimisations).
[^] # Re: Apple me gonfle
Posté par B16F4RV4RD1N . Évalué à 2.
Je présume quand même que cette conception a un impact sur l'affichage. Si ce n'est pas le cas, tant mieux ! Je n'ai pas assez testé des applications Qt4, par contre celles que j'avais vu avaient de superbes effets très fluide pour par exemple réorganiser les barres de menus (dolphin, konqueror...)
(et initialement je répondais juste à l'attaque comme quoi Mac OS X n'avait pas X11)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Apple me gonfle
Posté par inico (site web personnel) . Évalué à 4.
X en mode local n'utilise pas la pile réseau mais un beau socket Unix qui est trés rapide.
Le seul truc qui serait peut-être plus rapide, ce serait de mettre X dans le kernel et personne ne veut ça.
[^] # Re: Apple me gonfle
Posté par Ph Husson (site web personnel) . Évalué à 2.
Pas la peine de resortir un troll qui a mon age ... (bon ok j'exagere il doit avoir que la moitié de mon age.)
[^] # Re: Apple me gonfle
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Apple me gonfle
Posté par z a . Évalué à 2.
# Sécurité
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Sécurité
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
Hop, retour au point de départ.
[^] # Re: Sécurité
Posté par M . Évalué à 3.
Parce que tu t'amuse à exécuter les *.jpeg ?
IIRC c'est plus les utilitaires sous une certaine platformes qui sont moisi.
Et puis tromper libmagic en présentant une fausse signature, c'est pas non plus mission impossible.
[^] # Re: Sécurité
Posté par Yusei (Mastodon) . Évalué à 2.
Après on peut évnetuellement mélanger les deux approches, c'est à dire parser le fichier pour déterminer son type, stocker l'info dans des méta-données et re-calculer dès que les méta-données sont "périmées".
[^] # Re: Sécurité
Posté par Mildred (site web personnel) . Évalué à 2.
Avoir le type du fichier physiquement dans le fichier erait une très bonne approche mais irréalisable sans tout casser.
Personnellement, ce que j'ai immaginé un jour c'est que tout fichier débute avec des lignes d'en-tête qui permettent de spécifier des choses comme le type de fichier, son encodage, et d'autres choses. Comme les en-tête des e-mails ou les en-tête HTTP.
Mais cela voudrait dire devenir incompatible avec tous les formats de fichiers existants.
Malhereusement, aucune solution idéale existe. Si il était possible de modifier le magic number d'un fichier tar ou gzip afin de refléter le type du fichier inclus, ce serait parfait, mais je ne crois pas que ce soit possible.
Bon, je vais répondre à d'autres messages au dessus ... Concernant les extensions de fichiers, il est vrai que dans certains contexte, il semble judicieux de les garder (en programmation pour différencier toto.c, toto.h et toto.o. Mais dans un contexte plus orienté bureautique, l'extension du fichier n'a pas a exister. Pourquoi obliger les utilisaeurs à rajouter .odt après leur document texte
[^] # Re: Sécurité
Posté par Antoine . Évalué à 2.
Si je veux produire une version PDF du document ça peut être utile non ?
[^] # Re: Sécurité
Posté par Lebas Sébastien . Évalué à 2.
Ou une version audio et audio + vidéo d'une chanson ...
Ou un fichier et sa version zippée ...
[^] # Re: Sécurité
Posté par Gniarf . Évalué à 8.
1) en quoi un contexte "plus orienté bureautique" serait différent d'un environnement de programmeurs et autres administrateurs système, si ce n'est que tu impliques silencieusement que ces utilisateurs se foutent des détails informatiques tant que ça marche ? qu'ils sont blonds, en gros ? et les graphistes, ils puent ? eux ils veulent vraiment faire la différence entre un TIFF et un PCX, parce que l'un des deux prendra 5 minutes à se charger dans Photoshop s'il ne fait pas planter la machine en cours de route.
2) pourquoi obliger les utilisateurs à enlever l'extension .odt après leur document OpenOffice.org Writer alors que l'application l'a mise toute seule comme une grande ? ne serait-ce que pour que elle puisse y retrouver ses petits : c'est une tache inutile, voire dangeureuse.
3) en fait ton "contexte" existe déjà. tu vas le trouver dans les web applications comme celles de Google, ou dans les ajouts de Microsoft Office (Nouveau document Office, Ouvrir un document Office, la barre d'outils Office qui fait launcher d'applications et sûrement des documents récents aussi). ou dans le mini-bureau de StarOffice avec son explorateur : c'est fermé, normatif, et ca ignore complètement le reste du monde : tant pis pour ce qui n'était pas prévu. oh, oui, souvent c'est extensible, mais pas par l'utilisateur de base.
4) mais sinon ça n'a de sens que si tu as une seule application à utiliser toute la journée. genre une suite Office, ou d'ailleurs Works : c'est elle qui devient ton contexte, ton environnement. les utilisateurs feront fichier-ouvrir et l'application ne montrera que les documents reconnus. dans le monde réel, tu auras souvent plus d'applications nettement dissociées et ils utiliseront alors un file manager. avoir .doc de marqué est aussi important que d'avoir une icone Word, c'est une information visuelle et utile, même si elle parait redondante
je pense que retirer de l'information va aliéner les utilisateurs, les rendre plus idiots, plus dépendants. dans pas mal de cas c'est utile ou même nécessaire, mais sinon tu vas les transformer en utilisateurs d'interfaces Adibou (qui a dit Gnome ?) : si tu les en sors, ils seront vraiment perdus.
[^] # Re: Sécurité
Posté par Tonton Th (Mastodon) . Évalué à 6.
{tTh} moi.
[^] # Re: Sécurité
Posté par Mildred (site web personnel) . Évalué à 1.
Pas du tout. C'est juste ce que je ressens.
Par exemple lorsque je programme je fais attention a ne pas mettre d'espaces dans les noms de fichiers, a mettre une extension, a avoir des noms de fichiers simples ...
Ça c'est dans mes projets.
Par contre, lorsque je fait des documents, des rapports, des images, lorsque je gère ma musique je mets des espaces, des caractères accentués et autres joyeusetés (même si cela devient difficile a utiliser en mode console, mais généralement je n'ouvre pas ma console sur ces dossiers)
Et je cherche effectivement dans mon dossier ~/Documents à ne pas mettre d'extensions (en espérant que libmagic ne se trompe pas).
Dans ce contexte, je pense que le nom du fichier doit au maximum représenter son contenu et je me paserait bien de ces extensions qui sont moches comme tout.
Finalement, je crois que j'aimerais bien avoir comme dans Windows un navigateur de fichier qui me cache l'extension, ou plutôt me l'affiche à part et me laisse la modifier à part du nom.
Et concernant ton histoire de TIFF et XCF rien n'empêche le navigateur de fichier d'indiquer le type de fichier en dessous de son nom. Je fais déjà cela avec la taille dans Nautilus. Et personellement l'icone me suffit.
Rien n'empêche aux utilisateurs de l'enlever, ou même de la mettre. c'est juste que je pense que le navigateur ne devrait pas reposer sur l'extension pour déterminer le type du fichier. Et libmagic n'est pas suffisament fiable.
Qui veut retirer l'information ? Je souhaite juste la placer à un autre endroit et la sortir du nom du fichier où elle n'a rien à faire.
[^] # Re: Sécurité
Posté par Gniarf . Évalué à 4.
donc si je déplace et sors 100 euros de ta poche où ils n'ont rien à faire là (parce que c'est mon opinion juste et bonne) pour les placer à un autre endroit comme dans ma poche je ne te vole pas ?
faut qu'on se voit de suite
[^] # Re: Sécurité
Posté par Lebas Sébastien . Évalué à 2.
Je plussoie violemment ...
Et je fait remarquer dans la foulée que le contenu d'un d'un fichier est extraordinairement lié à son type (qui est reflété par son extension donc ;) ) ...
Ben là, on est dans l'appréciation graphique pure ... Ca doit pouvoir se gérer juste avec une option d'IHM, donc ? (Ce que tu confirmes juste après ;) ).
[^] # Re: Sécurité
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Sécurité
Posté par Gniarf . Évalué à 2.
sous Mac OS vers 1992 j'ai vu qu'on pouvait affecter des couleurs aux noms de fichiers dans le Finder : jaune, cyan, tout ça. c'est bizarre, ça n'a pas pris...
[^] # Re: Sécurité
Posté par Thomas Douillard . Évalué à 2.
En gros c'est plus un problème d'existant qu'un problème de conception technique.
[^] # Re: Sécurité
Posté par Gniarf . É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)
[^] # Re: Sécurité
Posté par Mildred (site web personnel) . Évalué à 2.
Pour prendre un exemple que beaucoup de monde doit utiliser : nautilus, il m'est souvent arrivé de voir des fichiers dont le type était mal reconnu. Et d'avoir des problèmes à cause de cela.
Alors ce n'est peut être pas le boulot de libmagic (et j'en suis d'accord) mais c'est forcément le boulot de quelqu'un ... Je n'ai rien contre libmagic en tant que telle, mais j'en à la sur-utilisation qui en est faite pour détecter les types de mes fichiers.
[^] # Re: Sécurité
Posté par Gniarf . Évalué à 2.
envoie un patch. en fait non, constate que les applications se débrouillent quand même bien comme c'est, quand OpenOffice s'est mis à prendre de l'ampleur les applications qui en avaient quelque chose à faire (les file managers, en gros) sont devenus OpenOffice-aware, elles reconnaissaient ces documents.
Pour prendre un exemple que beaucoup de monde doit utiliser : nautilus, il m'est souvent arrivé de voir des fichiers dont le type était mal reconnu. Et d'avoir des problèmes à cause de cela.
ben en fait, que ce soit avec une extension, un mime-type, un header contenant une signature précise, ou tout autre système ... le fichier lui-même peut être corrompu, incomplet (transfert interrompu, plantage à l'écriture). Nautilus aura du mal s'il tente de faire un aperçu dessus.
il y a d'ailleurs de bonnes blagues avec l'explorateur de Windows quand il va chercher des icones dans des fichiers qu'il prend pour des executables : s'il se plante dessus, il laisse le fichier ouvert en lecture, du coup impossible de l'éffacer "ce fichier est utilisé par Windows", du coup il faut tuer l'explorateur ou rebooter. génant sur le Bureau...
d'ailleurs tu es bien conscient qu'il m'est possible d'inventer indéfiniment de nouveaux types de fichiers et d'entêtes ? c'est le théorème d'incomplétude de Gödel qui veut ça. libmagic et les applications en dépendant seront toujours incomplètes. et même sans ça, il m'est toujours possible d'affecter des métadonnées fausses (ou un contenu arbitraire voir malicieux) à tout système que tu me présenteras...
[^] # Re: Sécurité
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Sécurité
Posté par Thomas Douillard . Évalué à 1.
Ouais, ou une meta donnee type "zip/xml/svg" qui ne demande aucune ressource à parser et ton navigateur qui te propose d'ouvrir ton archive avec soit un désarchiveur soit un éditeur xml soit inkscape suivant les applis installées et ce qu'elle ont déclarées pouvoir ouvrir, le tout sans avoir besoin de parser/décompresser quelque donnée que ce soit dans ton fichier.
[^] # Re: Sécurité
Posté par Gniarf . Évalué à 2.
[^] # Re: Sécurité
Posté par fmaz fmaz . Évalué à 2.
Tu sais, les conteneurs, ça existe: matroska, divx, tar.
Il suffit, pour l'échange, de faire un conteneur qui emballe le fichier et les meta-données et hop, pas de problème.
Et je me dis pas que c'est pénible. C'est pénible si on a pas les outils pour gérer automatiquement ces conteneurs. Je rappelle que tous les hacks à la libmagic ou les heuristiques pour deviner l'encodage d'un texte, ça a un coût.
[^] # Re: Sécurité
Posté par Ph Husson (site web personnel) . Évalué à 3.
Genre ce que fait file -z ?
[^] # Re: Sécurité
Posté par Mildred (site web personnel) . Évalué à 1.
Ce que je cherchais c'était plutôt de modifier le magic number du fichier gzip afin qu'il ne soit plus identifié comme fichier gzip mais comme un autre type de fichier. Sans qu'il soit nécessire de décompreser le fichier pour voir
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.