Journal personne n'aura besoin de plus de 640ko de RAM

Posté par  (site web personnel) .
Étiquettes : aucune
-3
6
mai
2009
C'est bien connu de tout le monde : " personne n'aura besoin de plus de 640ko de RAM ".

Aujourd'hui, tout le monde sourit quand on entend cette citation d'un illustre personnage.

Par contre, tout le monde sait que les noms de fichiers longs ne dépasseront jamais 255 octets.
enfin, si ... les devs de l'ext4 on prévu le besoin et donc, ils ont préféré en mettre 256.

C'est vrai quoi, pourquoi pourrait on avoir besoin de stocker un fichier avec un nom extrêmement long ?
- la complétion n'existe pas, donc, il faut se taper les 40 000 caractères un par un
- si la complétion peut aider, pourquoi ne pas compresser le nom en une suite de caractères complètement imcomprehensible car perdant sa signification ? un nom de fichier ne doit il pas etre intelligible ?
- un nom de fichier correct se doit d'etre en ASCII 7 ! les UTF-machins pouvant compter jusqu'à 4 octets, c'est le mal !
- c'est tellement plus rapide que faire un grep -r qu'un find -name
- bon sang ! je n'ai qu'à stocker les extras dans un SQLite ou un MySQL, non ?

plus sérieusement, si ext4 est un intermédiaire à BTRFS, pourquoi meme dans ext 4 et BTRFS la possibilité de mettre un de nom réellement long n'est pas possible ?

et puis, pourquoi 255 caractères ? pourquoi pas 640 ? cela aurait été un bon clin d'oeil pour de la limite arbitraire, stupide, inutile et contraignante ?

  • # Pourquoi 255?

    Posté par  . Évalué à 5.

    Pourquoi 255? Calcule (2^8 - 1) pour voir?

    Je sais pas comment c'est foutu en interne, mais il y a peut-être un octet qui est utilisé pour stocker la taille du nom...
    Doubler la taille pourrait permettre de monter jusqu'à 65535, et prendrait 1 octet de plus par fichier sur le disque dur, ils ne veulent peut-être pas perdre de place, ou peut-être est-ce pour la compatibilité ext3?

    • [^] # Re: Pourquoi 255?

      Posté par  (site web personnel) . Évalué à 10.

      Euh j'ai du mal à imaginer le besoin d'aller au delà même si cette limite paraît stupide.
      quelqu'un a t-il déjà souffert de cette limitation ?

      • [^] # Re: Pourquoi 255?

        Posté par  . Évalué à 4.

        quelqu'un a t-il déjà souffert de cette limitation

        pas moi. Donc 255 caractères iz énouff.

        J'aimerais bien que l'auteur du journal nous présente un exemple concret de limitation, parce que là je ne vois pas. Et comme dit plus bas, autant avoir un bon système de metadata qui rajoutera des tags par exemple, plutôt que de tout mettre dans le nom de fichiers ce qui le rend illisible.

        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: Pourquoi 255?

          Posté par  . Évalué à 8.

          moi j'ai déjà vu des plugins eclipse ayant des fichiers avec des noms trop long pour l'utilitaire de dézipage fourni avec l'ordinateur du boulot (le nom était un truc du style org__machin__nom_du_plugin__nom_du_package__nom_du_sous_package__morceau_sans_intérêt__version_a_rallonge_(alpha)__kikoulol__asv.jenesaisplusquoi. Par contre, je ne me rapelle pas de la longueur exacte.

          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

          • [^] # Re: Pourquoi 255?

            Posté par  . Évalué à 0.

            donc c'est la faute de ext4 qui limite les caractères à 255 si les zip pour eclipse ne s'ouvrent pas avec cet utilitaire de dézipage (laisse moi deviner winzip ?)

            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: Pourquoi 255?

              Posté par  . Évalué à 6.

              Elle est bizarre ta déduction (je parle du "donc", pas de winzip)
              Non, c'est juste un exemple de "comment arriver à un nom de fichier très (trop) long.

              Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

              • [^] # Re: Pourquoi 255?

                Posté par  . Évalué à 2.

                En l'occurence, ce n'est pas le nom de fichier qui est trop long, mais le path complet. Et c'est une limite du format zip lui même (ou de son implémentation), qui est de l'ordre de 255 caractères aussi. Sinon sous Linux, la longueur maximale d'un path est de 1024 (ou 1023 ?) caractères.

                • [^] # Re: Pourquoi 255?

                  Posté par  . Évalué à 1.

                  Pour le path maximal, ca dépend, il faut appeler pathconf(3) pour le savoir (chez moi c'est 4096). Le man de realpath(3) semble aussi indiqué que cette taille n'a pas être fixe.

              • [^] # Re: Pourquoi 255?

                Posté par  . Évalué à 2.

                il n'a pas expliqué que le nom de fichier posait problème avec le systèe de fichier, mais avec l'utilitaire de dézippage, d'où ma déduction.

                (ayant des fichiers avec des noms trop long pour l'utilitaire de dézipage )

                En plus il n'a pas précisé le nombre de lettres, si cela se trouve c'était 50 ou 150, en plus le problème était peut-être plutôt lié au chemin complet.

                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: Pourquoi 255?

            Posté par  (site web personnel, Mastodon) . Évalué à 0.

            J'ai eu le cas sur des noms de fichiers contenant des patches, nommés du genre patch-rep1__rep2__...__repn__nom_fich qui ne posaient pas de problème en UFS, mais qui étaient mangés si on les gravait sur un CD en Joliet, ce qui provoquait des doublons.

            • [^] # Re: Pourquoi 255?

              Posté par  (site web personnel) . Évalué à 3.

              En même temps, dans ce cas de figure c'est Joliet qui limite à 64 caractères ce qui est vraiment pas énorme ...

              Autant dépasser 64 caractères est assez fréquent autant 255 l'est beaucoup moins ...

    • [^] # Re: Pourquoi 255?

      Posté par  . Évalué à -3.

      Je pense que le "- 1" correspond au \0 qui termine toute chaine de caractères sous Unix au moins

    • [^] # Re: Pourquoi 255?

      Posté par  . Évalué à -3.

      J'ai quand même une question (ça m'intéresse, car on est toujours à la recherche d'un moyen de gagner de la place dans nos logiciels, en ram ou eeprom)

      Comment stockes-tu 255 caractères dans un octet, exactement ? (même question avec 256)

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Pourquoi 255?

        Posté par  . Évalué à 3.

        Ok, je ne suis pas encore bien réveillé, désolé. /delete message /o\

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Pourquoi 255?

        Posté par  . Évalué à 5.

        Qui a dit que le nom était stocké dans un octet ?
        Si tu lit correctement le monsieur : il y a peut-être un octet qui est utilisé pour stocker la taille du nom

      • [^] # Re: Pourquoi 255?

        Posté par  . Évalué à 3.

        Comment stockes-tu 255 caractères dans un octet, exactement ? (même question avec 256)
        Relie le post auquel tu réponds, l'auteur à écrit (la mise en gras est de moi) :
        Je sais pas comment c'est foutu en interne, mais il y a peut-être un octet qui est utilisé pour stocker la taille du nom...

        • [^] # Re: Pourquoi 255?

          Posté par  . Évalué à 2.

          suffisait lire la première réponse au message auquel tu réponds pour comprendre la raison du message ...

    • [^] # Re: Pourquoi 255?

      Posté par  . Évalué à 9.

      Cela me rappelle quand j'étais môme et que je jouais au jeu Zelda sur NES. On ne pouvait pas aller au dessus de 255 gemmes dans son inventaire. J'étais frustré de ce chiffre arbitraire, tout autant que 999, ça prend la même place sur l'écran.

  • # structure des disques

    Posté par  (site web personnel) . Évalué à 10.

    Il y a une limite a ne pas oublier : c'est qu'un file system doit assurer l'intégrité des données qu'il doit stocker, or un secteur de disque dur (encore pour un bon moment la reference du stockage commun) fait 512 octets, pas plus.
    Si tu commence a répartir tes inodes (la structure qui reference un objet dans un file system) sur plusieurs secteurs, qu'est ce qui te garantit que l ón ne va pas couper l'electricité entre 2 secteurs concernant tes grosses inodes ? alors qu'un secteur s'écrit en une seule fois par le controleur du disque, sans risque de ce genre.
    Donc on ne dispose pas de plus de 512 octets pour decrire un fichier dans le file system, et on a pas que son nom a conserver, mais aussi les differentes dates, id, droits, type, proprietaire ...
    donc 255 ou 256, 'est deja pas si mal, ou alors il faut reinventer les disques durs avec des plus gros secteurs, mais on va tout casser. compatibilité quand tu nous tiens ...

    • [^] # Re: structure des disques

      Posté par  . Évalué à 7.

      Pour info, NTFS supporte les noms jusqu'a 32768 caracteres, et cela sans probleme, et c'est de loin pas le seul FS a le faire.

      Les coupures d'electricite c'est pas un probleme, c'est a ca que sert un journal

      A mon avis c'est plus du a des problemes de compatibilite avec qqe chose d'existant, mais je ne saurais dire quoi.

      • [^] # Re: structure des disques

        Posté par  (site web personnel) . Évalué à 10.

        D'après wikipedia, ce sont les chemins qui sont limités à 32768 caractères, les fichiers sont bien limités à 255. Faut-il le corriger sur ce point ?

        D'ailleurs, en regardant la comparaison, il semblerait qu'à part ReiserFS/4, tous les autres FS limitent à 255 octets ou caractères UTF-16.

        • [^] # Re: structure des disques

          Posté par  . Évalué à 2.

          Vraiment vraiment ?

          Je me souviens de m'être cogné la tête contre les murs avec des fichiers dont le nom+extension dépassait 255 caractères sur un serveur de fichiers Windows.

          Avec certaines applicatons (toutes de Microsoft et récentes: windows XP, Word 2000, etc.) je pouvais voir/modifier mes fichiers, avec d'autres j'avais des messages d'erreur.

          BeOS le faisait il y a 20 ans !

          • [^] # Re: structure des disques

            Posté par  . Évalué à 6.

            Je crois que c'est un problème d'API : NTFS autorise les chemins jusqu'à 32768 caractères, mais les API C au-dessus n'acceptent que des chemins beaucoup plus courts. Mercurial a eu des problèmes avec ça. Voir :
            http://www.selenic.com/mercurial/bts/issue839
            http://www.selenic.com/mercurial/wiki/fncacheRepoFormat

            Voir aussi :
            http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

            « In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. »

            Suivi de :

            « The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function. To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\<very long path>". (The characters < > are used here for visual clarity and cannot be part of a valid path string.) »

            Amusant non ?

            • [^] # Re: structure des disques

              Posté par  . Évalué à 2.

              Au boulot sur le poste d'un utilisateur (sous windows XP) j'ai déjà eu besoin de raccourcir les noms de plusieurs répertoire imbriqués les uns dans les autres pour récupérer des fichiers qui se trouvaient dans des sous sous sous sous sous sous sous sous...... répertoires. Car à partir d'un certain niveau je n'arrivais plus à ouvrir les répertoires pour continuer de descendre.
              J'ai du mal à imaginer comment on peut avoir besoin d'en arriver là. Mais le plus con c'est que le système d'exploitation ai laissé faire ça.

            • [^] # Re: structure des disques

              Posté par  . Évalué à 4.

              je pourrais parler d'un répertoire nommé toto.. (oui, avec deux points au cul), créé par un client FTP (filezilla) sur du NTFS, et ben Windows il veut plus le virer :)

              • [^] # Re: structure des disques

                Posté par  . Évalué à 3.

                Si tu utilises la notation cannonique (avec \\?\ devant) tu pourras, car il n'essaiera pas d'interpreter le chemin

                • [^] # Re: structure des disques

                  Posté par  . Évalué à 2.

                  Ouah, là il faut connaitre. en gros il faut taper rmdelete \\?\toto.. ?

                  Pas très user frendly, mais peut-être marqué dans l'aide ?

                  Par contre, dans l'explorateur, ne pas pourvoir le virer me semble plus gênant. Maintenant, comme il n'était pas indiquer de quelle manière il essayé d'effacer le fichier...

                  • [^] # Re: structure des disques

                    Posté par  . Évalué à 3.

                    ca a été un poil plus couillu car il y avait d'autres fichiers & repertoires dedans (invisibles à mes yeux car le listage plantait avant), donc un rmdir depuis l'invite de commandes ne suffisait pas. un rmdir /s un répertoire au dessus c'est passé.


                    mais moi je m'en fous, hein. dans le pire des cas un boot sur un vrai système et hop je n'étais plus emmerdé.


                    le problème c'est madame Michu à qui ça aurait pu arriver, hein, c'est un peu du même calibre que des fois quand tu télécharges un programme sur ton bureau, que le gentil Explorateur va essayer de zieuter dedans s'il y a des icones ou des ressources pour deviner quelle icone afficher, et qu'il se bloque parce que les données dedans sont encore pour l'instant du n'importe quoi, le fichier n'étant pas complètement téléchargé. du coup il reste un handle d'ouvert sur ce fichier .exe et d'une tu te prends une erreur d'écriture pas claire du tout à la fin du téléchargement et de deux tu ne peux pas enlever ce .exe corrompu et inutile sans redémarrer ou tuer l'explorateur (et des fois ce con se précipite à nouveau dans ce fichier .exe et s'arrete à nouveau, les quatre fers en l'air et le fichier ouvert donc invirable...)

      • [^] # Re: structure des disques

        Posté par  (site web personnel) . Évalué à 4.

        le cas d'un fs journalisé change en effet la donne puisque l'inode principale finalisant l'indexation de l'objet est posée en dernier, si on coupe avant, celles ecrites avant seront soit perdues, soit dans le journal pour la prochaine synchro.
        apres 32768 caracteres, on finirait presque par stocker les données dans le nom plutot que dans le fichier lui meme ... un FS plus gros que les données qu'il contient a l'extrème si la taille moyenne des fichiers est sous cette barre :/ On pourrait meme presque y faire de la stégano [:totoz]

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: structure des disques

        Posté par  . Évalué à 2.

        J'aimerais voir ca !
        Au delà de 256 caractère path+nom compris, j'ai des soucis pour
        ouvrir/supprimer/renommer des fichiers mais bizarrement pas les copier dans un path plus long
        Obligé de renommer les répertoires parents en plus court pour contourner la limitation.

        • [^] # Re: structure des disques

          Posté par  . Évalué à 2.

          Arf ! Dsl, j'avais pas lu toutes les réponses.

          Maintenant la question est: Y a t'il une API qui contourne le pb ?

    • [^] # Re: structure des disques

      Posté par  (site web personnel) . Évalué à 0.

      Il y a une limite a ne pas oublier : c'est qu'un file system doit assurer l'intégrité des données qu'il doit stocker, or un secteur de disque dur (encore pour un bon moment la reference du stockage commun) fait 512 octets, pas plus.
      Si tu commence a répartir tes inodes (la structure qui reference un objet dans un file system) sur plusieurs secteurs, qu'est ce qui te garantit que l ón ne va pas couper l'electricité entre 2 secteurs concernant tes grosses inodes ? alors qu'un secteur s'écrit en une seule fois par le controleur du disque, sans risque de ce genre.
      Donc on ne dispose pas de plus de 512 octets pour decrire un fichier dans le file system, et on a pas que son nom a conserver, mais aussi les differentes dates, id, droits, type, proprietaire ...
      donc 255 ou 256, 'est deja pas si mal, ou alors il faut reinventer les disques durs avec des plus gros secteurs, mais on va tout casser. compatibilité quand tu nous tiens ...

      c'est d'ailleurs pour la même raison que tu as que des fichiers de 512 octets sur ton disque ?

      parce que qui te dit que tu ne vas pas avoir de problème électrique au moment où tu seras en train d'écrire ton fichier ?

      et tu utilises aussi l'algo de I2BP pour assurer une tres bonne qualité de la zik que tu as sur ton disque, et ce, en 512 octets ?

      si le problème n'existe pas pour un contenu de fichier, pourquoi existerait il pour un nom ? au pire, ca fini dans lost+found comme tous les blocs qui ont un problème du fait d'une coupure au mauvais moment.
      non ?

      • [^] # Re: structure des disques

        Posté par  . Évalué à 3.

        si le problème n'existe pas pour un contenu de fichier, pourquoi existerait il pour un nom ?

        Parce qu'on ne traite pas de la même manière des données et des métadonnées?

        Idem dans un SGBD(R) : pourquoi on ne met pas toutes les colonnes comme index?

        • [^] # Re: structure des disques

          Posté par  (site web personnel) . Évalué à 1.

          la méta donnée est une donnée non ? si on applique la pensée unixienne " tout est fichier " ... les méta données devrait être un fichier en tant que tel non ? passons le troll sur la philosophie unixienne ;)

          tu parles des SGBDR, pour ce qui est du pourquoi de ta question, la réponse est double :
          - tu n'indexes que ce que tu sais devoir rechercher tôt ou tard
          - tu n'indexes que ce que tu ne mets pas à jour trop fréquemment

          Et sur ce coup, les index au niveau des SGBDR est juste un contournement lié aux performances catastrophiques du modèle relationnelle.

          Le modèle relationnel est est bien pour rechercher des informations, pas pour naviguer dans l'information ( la nuance est subtile et l'aparté serait trop longue à développer. Entre autre, Codd & Date sont de saines lectures sur le sujet ).

          Et ta comparaison avec les index ne sert a rien puisque les index sont accessoires, et sont des doublons reconstructibles des données déjà existantes.

          pour ce qui est de la FS, quelque soit la taille des méta données, elles auront toujours une taille moindre par rapport aux données. Donc leur écriture sera toujours plus rapide. et quand on modifie un fichier, on ne modifie pas à chaque fois les méta données et encore moins l'ensemble des méta données.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: structure des disques

              Posté par  . Évalué à 6.

              Dans ce cas, si tout est fichier, t'as un fichier pour la date de lecture/écriture du fichier. Et un fichier pour la date de lecture évcriture de ce fichier. Et ...

            • [^] # Re: structure des disques

              Posté par  (site web personnel) . Évalué à 2.

              par exemple, tu as noatime pour ne pas mettre à jour la derniere lecture en date :P

              c'est tres utile sur des serveurs qui chargent un peu trop ...

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 2.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: structure des disques

                  Posté par  (site web personnel) . Évalué à 2.

                  ce n'est pas la premiere erreur de conception du à une mauvaise conscience de la scalabilité ... ni la derniere ...

                  Je n'utilise le noatime que dans certains contextes.

                  Et sinon, je fais comment pour disposer de nom de fichiers de plus de 255 caractères ?

                  Plus court ? non.
                  Une BDD genre MYSQL ? et tant qu'à faire du TOMCAT/JBOSS ?
                  SQLite ? beurk.
                  BDB & co ? pourquoi pas ... mais niveau maintenabilité ca pue un peu.

                  si quelqu'un a une solution autre, je suis preneuse :)

                • [^] # Re: structure des disques

                  Posté par  (site web personnel) . Évalué à 2.

                  Casser des applications est grandement exagéré. Pour mutt, le seul problème à être en noatime est que si tu as une boîte en mbox, il ne saura pas si tu as lu les derniers mails reçus, dans tous les autres cas, ça marche parfaitement, et même dans ce cas, on ne peut pas dire que ce soit cassé (juste désagréable).

          • [^] # Re: structure des disques

            Posté par  . Évalué à 2.

            la méta donnée est une donnée non ? si on applique la pensée unixienne " tout est fichier " ... les méta données devrait être un fichier en tant que tel non ? passons le troll sur la philosophie unixienne ;)

            Unix a surtout su quand arrêter la philosophie pour passer aux réalisations pratiques. Et ils se sont vite rendus compte que ce genre de boucles conceptuelles, si c'est très élégant intellectuellement, ça peut devenir dangereux ("z'avez pas vu ma pile?").

            C'est d'ailleurs, si je ne m'abuse, un des chevaux de bataille de Plan9 : pousser cette fameuse philosophie à l'extrême. Et si on veut pousser cet extrême à l'extrême, on se retrouve avec un Hurd qui marche :>

      • [^] # Re: structure des disques

        Posté par  (site web personnel) . Évalué à 8.

        ce n'est pas le meme cas :
        si un fichier est coupé, on perds les données
        si une inode est perdue, et que ca concerne un repertoire de haut niveau, tu ne perds pas qu'un seul fichier ...

  • # Pour un vrai systeme de classement

    Posté par  . Évalué à 8.

    Je pense que l'idée d'une longueur limite dans un nom de fichier n'est pas vraiment contraignant et a peu de le devenir. Pourquoi ?

    Tout d'abord car on peut avoir l'arborescence qu'on veut. Si tu part sur Les photos du mariage du premier janvier 2009 entre la soeur du cousin a hector et le fils du neveux à mon beau frere : photos de tante marisette en train de prendre un verre de sangria avec son fils a coté de la table de la belle famille et notamment le frére du marié" (heureusement que la limite n'est pas 640, j'aurai fini par être totalement incoherent) Que peut on dire sur ce nom de fichier. Déjà, si il y en a plusieurs de ce genre, autant les mettre dans un dossier, ce sera plus lisible. Niveau affichage dans un navigateur de fichiers, c'est assez énorme, on ne voit pas tout de suite ce qu'il contient.
    Ensuite, pour stocker plein d'informations au sujet d'un fichier, les metadonnées me semblent plus interessantes si on peut faire directement des recherches dessus. Note que je ne sais pas ce qu'on peut faire aujourd'hui, je ne me suis jamais posé la question, j'aime le coté chaotique de mon rangement :o) . Mais si je devais demain ranger proprement, ce n'est pas de longs noms de fichiers que je veux mais pouvoir remplir mes fichiers metadonnées et faire des recherches dessus (mais sa doit bien exister non ?)

    • [^] # Re: Pour un vrai systeme de classement

      Posté par  . Évalué à 10.

      Toi aussi tu préfères une benne de DSC00014.jpg et _IGP4060.pef à une étagère d'albums plastifiés ?

      • [^] # Re: Pour un vrai systeme de classement

        Posté par  (site web personnel) . Évalué à 2.

        En ce qui me concerne, tout a fait.... Meme si je ne suis pas encore tres satisfait des softs linux dans le domaine, c'est toujour mieux d'avoir des jpeg et des pef que des dizaines d'armoires d'album....

        Madame aussi préfère ;)

      • [^] # Re: Pour un vrai systeme de classement

        Posté par  . Évalué à 3.

        Disons que je pense qu'il y a un juste milieu.
        Oh, et pour mon cas strictement personnel, je n'ai pas de photos donc en fait, c'est le cadet de mes soucis, par contre, pour mes autres documents, ils ont un vrai nom, souvent assez court, placé dans un dossier assez explicite.

        • [^] # Re: Pour un vrai systeme de classement

          Posté par  . Évalué à 1.

          Moi j'ai quelques milliers de photo.
          Pour garder des répertoires de taille raisonnable, l'arborescence est ainsi constituée :
          - un rep par an
          - un rep par mois
          - un rep par qui contient toutes les photos du jour.
          Le nom d'un fichier photo est AAMMJJ-HHMMSS-NuméroImage.ext

          Le numéro image est fourni par l'appareil et la date de prise de vue est dans les métadonnées de la photo enregistrée par l'appareil.

          comme ça les noms de fichiers restent de taille raisonnable.

          Toutes les infos complémentaires sont enregistrée en mata donnée IPTC dans les photos (tag, commentaire...)

          J'ai une base de donnée qui contient les infos complémentaires et qui me permet les recherches. (en fait je réutilise et j'enrichis celle de F-Spot)

          Le défaut c'est la non intégration à l'explorateur de fichier pour les recherches !

    • [^] # Re: Pour un vrai systeme de classement

      Posté par  . Évalué à 4.

      Mon nom de fichier le plus long est probablement «2004 - Beauquier, Crolard, Prokofieva - Automatic Parametric Verification of a Root Contention Protocol Based on Abstract State Machines and First Order Timed Logic.pdf»

      C'est un article scientifique, j'ai longtemps hésité pour ma convention de nommage, mais le plus simple c'est encore de tout noter (date, auteurs, titre) (et en utilisant des espaces). Et cela peut être long.

      Alors effectivement utiliser des métadonnés serait mieux, et d'ailleurs j'ai quelques fichiers pdf ou la métadonnée titre est bien saisie mais c'est rare. Ça arrive notamment quand l'auteur a utilisé le package latex hyperref, mais cela reste rare même si on regarde les pdf «officiels» des éditeurs.

      Sinon le système de gestion des métadonnés sous linux avance doucement, il faut regarder du coté de en:NEPOMUK_(framework) notamment. Mais c'est pas encore super au point.

      • [^] # Re: Pour un vrai systeme de classement

        Posté par  . Évalué à 3.

        Juste au passage, je te conseil Jabref pour sauvegarder tes biblios (et t'évitera les noms à rallonge :)

        Marc

      • [^] # Re: Pour un vrai systeme de classement

        Posté par  (site web personnel) . Évalué à 3.

        Les articles pdf que j'ai sont indexés dans un fichier bibtex (et aussi avec referencer [1] mais je ne l'ai pas encore adopté). Une moulinette fabrique aussi un index html très joli et je peux donc partager ma bibliographie avec mes collègues. Par contre, les noms de fichiers sont plutôt courts (Les 3 premières lettres des noms des 3 premiers auteurs, l'année, éventuellement le journal ou la conf) et ils sont les mêmes que les clefs bibliographiques comme ça, si je lis BeaCroPro2004.pdf, je sais que je dois le citer en \cite{BeaCroPro2004}.

        Mais si tu veux stocker les métadonnées dans le fichier, c'est possible (pdftk peut le faire par exemple, et pourquoi ne pas faire un script qui lit le fichier bibtex et ajoute les métadonnées si elles ne sont pas dans le pdf), ensuite, il sera indexé par ton indexeur automatique préféré.

        [1] http://icculus.org/referencer/

      • [^] # Re: Pour un vrai systeme de classement

        Posté par  . Évalué à 4.

        Pour ton histoire de PDF dont les métadonnées ne sont pas toujours remplies, tu peux jeter sur pdftk, qui sert à manipuler des PDF dans tous les sens, et permet entre autres de modifier ces fameux tags.

        La prise en main est assez simple et la page de man est assez claire, avec des exemples (je viens d'essayer avant de poster pour être sûr ;-) ).

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Pour un vrai systeme de classement

        Posté par  . Évalué à 3.

        165 caractères, ça va encore. Bien entendu, si tu dois rajouter l'université d'où cela vient, le nom des relecteurs, et l'âge du chien de la concierge, on va vite arriver à 255 lettres...

        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: Pour un vrai systeme de classement

      Posté par  . Évalué à 2.

      Il se trouve qu'hier, j'ai rencontré un fichier au nom très long: c'était un pdf généré via une base de données en ligne. Le nom du fichier contenait manifestement l'identifiant de session. On était pas loin de 255 caractères.
      J'imagine donc très bien un fichier généré contenant accidentellement plus de 255 caractères (comme il est dit ailleurs avec le titre d'un article scientifique par exemple).
      Tu me diras c'est généré, on ne le stocke pas. Ben si, moi je stocke et je dois changer le nom à l'enregistrement. Pas très difficile ni aussi contraignant que la limite des 640 Ko de Ram. Même si c'était fait par un script d'ailleurs.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Pour un vrai systeme de classement

        Posté par  . Évalué à 2.

        toi aussi tu télécharges tes relevés banquaire du crédit agricole en ligne ? ;)

        J'ai eu cela hier, un nom qui ressemblait à une id de session, horrible, j'ai immédiatement renommé avec un nom plus explicite (par exemple mon_releve_de_compte_du_01_mai_2009_avec_mon_achat_d'un_timbre_de_collection_sur_ebay,_les_trois_tomates_achetées_chez_carrouf_le_24_avril,_un_paquet_de_pates_luskilucru,_un_livre_pour_maitriser_netbsd_achete_chez_nafnaque_et_un_repas_pris_a_la_cantine_(c'était_pas_bon_j'aime_pas_les_raviolis).pdf)

        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  . Évalué à 6.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Pour un vrai systeme de classement

        Posté par  . Évalué à 1.

        De nos jours, on utilise utf-8 et la taille d'un caractère peut-être de plusieurs octets. Pour certains (grecs, russes, Chinois, ...)

        français aussi… (éèçàù…)

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Pour un vrai systeme de classement

            Posté par  . Évalué à 1.

            c'est certain mais même si 90 % des caractères ne sont pas accentués énormément de mot courants les utilisent

            • [^] # Re: Pour un vrai systeme de classement

              Posté par  . Évalué à 0.

              ca tombe bien, si j'en crois http://www.utf8-chartable.de/ l'essentiel des caracteres accentues latin se trouvent avant 0xFF.
              Donc un octet.

              Apres ya cette histoire de bits de poids fort qui donnent le nombre d'octets pour le caractere dont je ne me rappelle pas des details, donc potentiellement je dit une connerie et ca deborde sur 2 octets.

              • [^] # Re: Pour un vrai systeme de classement

                Posté par  . Évalué à 1.

                Le probleme c'est qu'il y a plein de gens sur cette planete qui n'utilisent pas l'alphabet latin :)

                Raison pour laquelle tu peux representer un caractere UTF-8 en jusqu'a 4 bytes, afin de pouvoir representer notamment les caracteres chinois.

                • [^] # Re: Pour un vrai systeme de classement

                  Posté par  . Évalué à 2.

                  oui oui, je sais bien, je reflechissais juste a voix haute sur cette histoire de caracteres accentues latins, il me semblait que UTF8 etait plus ou moins equivalent a ISO 8859-1 pour les caracteres usuels.
                  Apparement, c'est pas le cas, mea culpa, meat coule plus

              • [^] # Re: Pour un vrai systeme de classement

                Posté par  . Évalué à 2.

                En utf8 les caractères latins accentués sont codés sur 2 caractères (par exemple é=c3 a9), le code inférieur à 0xFF c'est le code point unicode qui est différent de sa représentation effective.

                • [^] # Re: Pour un vrai systeme de classement

                  Posté par  . Évalué à 3.

                  exact et on s'en rend compte par exemple lorsqu'il y a un problème d'encodage de pages web (contenu en utf8, affichage en ISO 8859-1) tous les caractères accentués, cédille et consort sont affiché avec 2 caractères…

      • [^] # Re: Pour un vrai systeme de classement

        Posté par  . Évalué à 4.

        En meme temps, en chinois, si je ne me trompe pas ce sont des idéogrammes. Et 80 idéogrammes pour un nom de fichier ca me parait pas mal quand meme, non ? A mon avis ca peut largement valoir 255 lettres.

  • # dirent

    Posté par  . Évalué à 2.

    au hasard, regarde sur google, la taille des noms de fichier est limité sur certains OS et il y a beaucoup de code qui font un bête sizeof(d_name).

    avoir une taille fixe, comme pour Linux de la structure dirent simplifie le code. Sinon tu peux utiliser Solaris > 10.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: dirent

        Posté par  (Mastodon) . Évalué à 3.

        sizeof(d_name) vs strlen(d_name)

        J'ai pas tout suivi, là... Tu mélanges avec allégresse la taille du contenant et la taille du contenu, non ?

        • [^] # Re: dirent

          Posté par  . Évalué à 5.

          tu peux avoir :
          struct dirent {
          ________[. . .]
          ________d_name[1];
          }

          la chaîne est incluse dans la structure dirent, "d_name" n'est pas un pointeur. donc il faut utiliser une macro pour connaître la vrai taille.

          Sous Linux :
          struct dirent {
          ________[. . .]
          ________d_name[255];
          }

          • [^] # Re: dirent

            Posté par  . Évalué à 0.

            J'ai pas bien compris ce que tu viens d'écrire.

            Mais si je ne m'abuse sizeof(d_name) vaut 4 sur une machine 32 bits et est calculé à la compilation. Ce n'est pas la longueur de la chaine, mais la "taille" du pointeur.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 3.

              Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: dirent

              Posté par  . Évalué à 3.

              Mais si je ne m'abuse sizeof(d_name) vaut 4 sur une machine 32 bits et est calculé à la compilation. Ce n'est pas la longueur de la chaine, mais la "taille" du pointeur.
              Non, il ne faut pas confondre : int *toto; et int toto[255].
              Même si toto renvoie bien un pointeur sur les données. Qui devront être préalablement allouée dans le premier cas, et le second ne peut-être une lvalue.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

  • # de ce temps là

    Posté par  . Évalué à 4.

    Du temps du '640 kb ought to be enough for anyone'
    Du temps du dos.
    c'était 8 caractères + 3 d'extensions sont suffisants. Ça c'était un peu rick rack, mais 255, j'ai jamais eu à me plaindre.

  • # Aucun rapport

    Posté par  . Évalué à 1.

    Tu compares une limitation sur des ressources et une limitation sur une manière d'accéder à des ressources...

    Permettre de donner des longs plus longs ajouterait pas mal de boulot aux développeurs
    (peut-être veux-tu contribuer sur ce point ? Je suis sur que Chris Mason sera content).
    Donc, s'il n'y a pas un intérêt autre que « une fois j'ai eu un fichier généré un peu long », il y a peu de chance qu'ils consacrent leur temps à ça...

    Je trouve que la limitation de la taille d'un fichier est bien plus importante
    (Heureusement on est assez large de ce côté maintenant..),
    parce que la taille des noms de fichier, ça me fait plus penser à un problème d'ergonomie...

  • # Métadonnées (grep vs find)

    Posté par  (site web personnel) . Évalué à 2.

    Je pense que le nom du fichier est bien moins utile que les méta-données d'un fichier. Exemple : pour trouver une photo, mieux vaut rechercher via la date stockée dans le fichier que via le nom du fichier => voir F-Spot. Idem pour trouver la musique : on recherche selon les méta-données (nom de l'artiste, titre de l'album, ...) => voir Amarok.

    Récemment j'ai entendu parlé de Gnome Zeitgeist (http://live.gnome.org/GnomeZeitgeist) qui généralise le concept (il doit exister d'autres logiciels dans ce genre).

    Et puis, n'oublions pas les Beagle & autres outil de recherche par mot clé (dans le contenu du fichier / les méta-donnéees).

    Les métadonnées peuvent être stockées dans le fichier ou en dehors : attributs dans le système de fichier (Mac OS utilise beaucoup ça) ou autre part (base de données à part).

    • [^] # Re: Métadonnées (grep vs find)

      Posté par  . Évalué à 1.

      Le problème des bases des métadonnées et qu'elles sont souvent plus lentes à chercher :
      - lire une partie du fichier quand ce n'est pas indexé (et interpréter le format, etc.)
      - temps d'indexation, et ne dites pas "l'indexation est incrémentale", prenez le cas de quelqu'un qui branche le disque dur externe d'un autre
      Mettre les métadonnées directement dans le système de fichiers (xattrs par exemple) n'est pas une solution non plus, pensez à un fichier que vous envoyez par mail, il passe où le système de fichiers ?

  • # Comme autre limitation idiote ...

    Posté par  (site web personnel) . Évalué à 3.

    On a la limite du nombre de clients sur un serveur X à 256. On peut penser que c'est suffisant, mais il faut croire que non. Ces derniers jours je n'ai pas cessé d'avoir des problèmes avec ça. Il y a en fait beaucoup plus de clients que de fenêtres visibles, par exemple, chaque applet sur le tableau de bord gnome est un client X11.

    http://www.x.org/wiki/Development/X12#head-780a667e54dfccd19(...)

    Vous pouvez essayer de lancer :

    xlsclients
    xwininfo -root -children

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.