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 ?
Journal personne n'aura besoin de plus de 640ko de RAM
6
mai
2009
# Pourquoi 255?
Posté par Damien Thébault (page perso, jabber id) . Évalué à 5.
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 Dup (page perso) . Évalué à 10.
quelqu'un a t-il déjà souffert de cette limitation ?
[^] # Re: Pourquoi 255?
Posté par farvardin (page perso, jabber id) . Évalué à 4.
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 ʇpooɹquooɥɔs sɐȷoɔᴉu (jabber id) . Évalué à 8.
La plupart des gens aiment recevoir des montants avec plein de zéros. Moi je préfère quand il y a plein de neufs.
[^] # Re: Pourquoi 255?
Posté par farvardin (page perso, jabber id) . Évalué à 0.
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 ʇpooɹquooɥɔs sɐȷoɔᴉu (jabber id) . Évalué à 6.
Non, c'est juste un exemple de "comment arriver à un nom de fichier très (trop) long.
La plupart des gens aiment recevoir des montants avec plein de zéros. Moi je préfère quand il y a plein de neufs.
[^] # Re: Pourquoi 255?
Posté par dyno partouzeur de drouate (page perso, jabber id) . Évalué à 2.
[^] # Re: Pourquoi 255?
Posté par bbfok . Évalué à 1.
[^] # Re: Pourquoi 255?
Posté par farvardin (page perso, jabber id) . Évalué à 2.
(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 Thierry Thomas (page perso, jabber id) . Évalué à 0.
[^] # Re: Pourquoi 255?
Posté par Enoch (page perso) . Évalué à 3.
Autant dépasser 64 caractères est assez fréquent autant 255 l'est beaucoup moins ...
[^] # Re: Pourquoi 255?
Posté par dguihal . Évalué à -3.
[^] # Re: Pourquoi 255?
Posté par ʇpooɹquooɥɔs sɐȷoɔᴉu (jabber id) . Évalué à -3.
Comment stockes-tu 255 caractères dans un octet, exactement ? (même question avec 256)
La plupart des gens aiment recevoir des montants avec plein de zéros. Moi je préfère quand il y a plein de neufs.
[^] # Re: Pourquoi 255?
Posté par ʇpooɹquooɥɔs sɐȷoɔᴉu (jabber id) . Évalué à 3.
La plupart des gens aiment recevoir des montants avec plein de zéros. Moi je préfère quand il y a plein de neufs.
[^] # Re: Pourquoi 255?
Posté par Jean B . Évalué à 5.
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 JAGUENAUD Anthony . Évalué à 3.
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 Elfir3 . Évalué à 2.
[^] # Re: Pourquoi 255?
Posté par oat5hd . Évalué à 9.
[^] # Re: Pourquoi 255?
Posté par Antoine Mercadal (page perso, jabber id) . Évalué à 5.
[^] # Re: Pourquoi 255?
Posté par imalip . Évalué à 10.
[^] # Re: Pourquoi 255?
Posté par Sylvain Sauvage . Évalué à 4.
# structure des disques
Posté par vincent LECOQ (page perso, jabber id) . Évalué à 10.
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 pasBill pasGates . Évalué à 7.
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 plop (page perso) . Évalué à 10.
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 dinomasque . Évalué à 2.
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 15 ans !
[^] # Re: structure des disques
Posté par Antoine . Évalué à 6.
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 tetaclac . Évalué à 2.
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 Gniarf . Évalué à 4.
[^] # Re: structure des disques
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: structure des disques
Posté par JAGUENAUD Anthony . Évalué à 2.
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 Gniarf . Évalué à 3.
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 vincent LECOQ (page perso, jabber id) . Évalué à 4.
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]
[^] # Re: structure des disques
Posté par alenvers (page perso) . Évalué à 2.
>je ne saurais dire quoi.
Tu ne sais pas dire quoi parce qu'il n'y a aucun problème de compatibilité. La taille maximale d'un nom de fichier est définie dans limits.h (NAME_MAX). Et tous les programmes quelque soit cette limite doivent en tenir compte.
$ getconf NAME_MAX .
[^] # Re: structure des disques
Posté par Bozo_le_clown . Évalué à 2.
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 Bozo_le_clown . Évalué à 2.
Maintenant la question est: Y a t'il une API qui contourne le pb ?
[^] # Re: structure des disques
Posté par Mouns (page perso) . Évalué à 0.
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 Larry Cow . Évalué à 3.
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 Mouns (page perso) . Évalué à 1.
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.
[^] # Re: structure des disques
Posté par alenvers (page perso) . Évalué à 1.
Est-ce que le moment d'écriture/lecture est une méta donnée pour toi ?
[^] # Re: structure des disques
Posté par Thomas Douillard . Évalué à 6.
[^] # Re: structure des disques
Posté par Mouns (page perso) . Évalué à 2.
c'est tres utile sur des serveurs qui chargent un peu trop ...
[^] # Re: structure des disques
Posté par alenvers (page perso) . Évalué à 2.
relatime
Update inode access times relative to modify or change time. Access time is only updated
if the previous access time was earlier than the current modify or change time. (Similar to
noatime, but doesn’t break mutt or other applications that need to know if a file has been
read since the last time it was modified.)
PS: Mais les 2 cassent la compatibilité POSIX
PS2: http://kerneltrap.org/node/14148
[^] # Re: structure des disques
Posté par Mouns (page perso) . Évalué à 2.
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 alenvers (page perso) . Évalué à 4.
Tu fais des répertoires.
[^] # Re: structure des disques
Posté par 태 (page perso, jabber id) . Évalué à 2.
[^] # Re: structure des disques
Posté par Larry Cow . Évalué à 2.
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 vincent LECOQ (page perso, jabber id) . Évalué à 8.
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 Guillaume Rossignol . Évalué à 8.
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 Pierre . Évalué à 10.
[^] # Re: Pour un vrai systeme de classement
Posté par Johann Ollivier-Lapeyre (page perso, jabber id) . Évalué à 2.
Madame aussi préfère ;)
[^] # Re: Pour un vrai systeme de classement
Posté par Gniarf . Évalué à 10.
[^] # Re: Pour un vrai systeme de classement
Posté par Guillaume Rossignol . Évalué à 3.
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 bertrand (page perso) . Évalué à 1.
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 outs . Évalué à 4.
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 Marc Dauwn . Évalué à 3.
Marc
[^] # Re: Pour un vrai systeme de classement
Posté par 태 (page perso, jabber id) . Évalué à 3.
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 zebra3 (jabber id) . Évalué à 4.
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 farvardin (page perso, jabber id) . Évalué à 3.
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 ZeroHeure (page perso, jabber id) . Évalué à 2.
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.
[^] # Re: Pour un vrai systeme de classement
Posté par farvardin (page perso, jabber id) . Évalué à 2.
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
[^] # Re: Pour un vrai systeme de classement
Posté par alenvers (page perso) . Évalué à 6.
http://kerneltrap.org/mailarchive/linux-ext4/2008/11/21/4189(...)
[^] # Re: Pour un vrai systeme de classement
Posté par jeffcom . Évalué à 1.
français aussi… (éèçàù…)
[^] # Re: Pour un vrai systeme de classement
Posté par alenvers (page perso) . Évalué à 4.
Tu as oublié de citer la suite qui est importante : "la limite est de +/- 80 caractères".
En français, >90% des caratère sont de l'ascii et donc sur 1byte ce qui nous donne une limite moyenne de bien plus haute.
[^] # Re: Pour un vrai systeme de classement
Posté par jeffcom . Évalué à 1.
[^] # Re: Pour un vrai systeme de classement
Posté par thedude . Évalué à 0.
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 pasBill pasGates . Évalué à 1.
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 thedude . Évalué à 2.
Apparement, c'est pas le cas, mea culpa, meat coule plus
[^] # Re: Pour un vrai systeme de classement
Posté par Franck V (jabber id) . Évalué à 2.
[^] # Re: Pour un vrai systeme de classement
Posté par jeffcom . Évalué à 3.
[^] # Re: Pour un vrai systeme de classement
Posté par campagnard . Évalué à 4.
# dirent
Posté par thedidouille . Évalué à 2.
avoir une taille fixe, comme pour Linux de la structure dirent simplifie le code. Sinon tu peux utiliser Solaris > 10.
[^] # Re: dirent
Posté par alenvers (page perso) . Évalué à 2.
http://www.opengroup.org/onlinepubs/009695399/basedefs/diren(...)
The name of an array of char of an unspecified size should not be used as an lvalue. Use of:
sizeof(d_name)
is incorrect; use:
strlen(d_name)
[^] # Re: dirent
Posté par Tonton Th (page perso) . Évalué à 3.
J'ai pas tout suivi, là... Tu mélanges avec allégresse la taille du contenant et la taille du contenu, non ?
Grmbl...
[^] # Re: dirent
Posté par thedidouille . Évalué à 5.
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 guppy . Évalué à 0.
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.
[^] # Re: dirent
Posté par alenvers (page perso) . Évalué à 3.
Non, tu t'abuses. Test :
struct plop {
int plop;
char ent[42];
};
int
main(int argc, const char* argv[])
{
struct plop p;
printf("Size: %d\n", sizeof(p.ent));
}
= 42
[^] # Re: dirent
Posté par JAGUENAUD Anthony . Évalué à 3.
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.
[^] # Re: dirent
Posté par alenvers (page perso) . Évalué à 3.
Le sizeof(str) d'un char str[42] est égal à 42 mais ici, la taille est non spécifiée, càd la structure est du genre :
struct dirent {
ino_t d_ino;
char d_name[]; // Pas de taille de tableau
};
La taille maximale d'un chemin est donnée par PATH_MAX de limits.h.
# de ce temps là
Posté par Rémi baudruche . Évalué à 4.
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 dohzya . Évalué à 1.
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...
[^] # Re: Aucun rapport
Posté par alice . Évalué à 2.
Il faut arrêter de lire les noms dans des buffers de taille fixe aussi...
[^] # Re: Aucun rapport
Posté par alenvers (page perso) . Évalué à 2.
char str[FILENAME_MAX + 1] est de taille fixe mais ne posera pas de problèmes...
[^] # Re: Aucun rapport
Posté par alice . Évalué à 5.
http://www.delorie.com/gnu/docs/glibc/libc_652.html
[^] # Re: Aucun rapport
Posté par alenvers (page perso) . Évalué à 2.
http://www.kohala.com/start/apue.html
ficher lib.44/pathalloc.c
[^] # Re: Aucun rapport
Posté par alice . Évalué à 2.
[^] # Re: Aucun rapport
Posté par Mouns (page perso) . Évalué à 1.
# Métadonnées (grep vs find)
Posté par Victor STINNER (page perso, jabber id) . Évalué à 2.
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 Octabrain . Évalué à 1.
- 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 Mildred (page perso, jabber id) . Évalué à 3.
http://www.x.org/wiki/Development/X12#head-780a667e54dfccd19(...)
Vous pouvez essayer de lancer :
xlsclients
xwininfo -root -children
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.