[ansi C] directory listing Fermé

Question

Hi all,Une carance dans la bibliothèque standard ansi C.Il n'y a pas de fonctions/structure standard avec le C ansi, pour faire lister les entrées d'un repertoire (je ne sais même pas si la fonction stat est standard).Il y a findfirt et findnext pour dos/windows, qui renvoie une structure bien renseignée, avec les attributs du fichier, la taille, date de création, modification, accés, ainsi que le nom de l'entrée. Parfait, c'est une fonction trés complète, rien à lui reprocher. Mais les fonctions dos/windows ne sont pas réputé pour être des standard.Il y a opendir/readir pour unix/linux, qui renvoie une structure dirent. Malheureusement, cette structure est pauvre en information, et ne contient ni les attributs, ni la taille, ni les dates d'accés/modification du fichier. En bref, rien (à ce demandé comment les concepteur de unix/linux on put se contenter de si peu).Je suis désagréablement surpris : comment ceux/celles qui ont concu le standard ansi ont-ils/elles puent ne même pas penser à cette fonction fondamental et vitale qu'est l'accès à un repertoire ?Je crois qu'il va donc falloir composé... quite à me créer ce que je considererai comme « mon standard ». Je pense me baser sur les fonctions de dos/windows, parce que ce sont de loin les plus complètes et les plus logiques. Mais j'aurais aimé quelque chose qui soit compatible posix par exemple, et qui soit au moins aussi fonctionelle que les fonctions de dos/windows.Quelqu'un(e) a des idées à ce sujet ?(il s'agit là plutôt d'une discussion, car je ne pense pas qu'il y ait *une* réponse exacte)Merci beaucoup

jisisv · Answer

Extrait de man 2 statThe stat() and fstat() calls conform  to  SVr4,  SVID,  POSIX,  X/OPEN,       4.3BSD.   The lstat() call conforms to 4.3BSD and SVr4.etint stat(const char *path, struct stat *buf);struct stat {              dev_t     st_dev;     /* ID of device containing file */              ino_t     st_ino;     /* inode number */              mode_t    st_mode;    /* protection */              nlink_t   st_nlink;   /* number of hard links */              uid_t     st_uid;     /* user ID of owner */              gid_t     st_gid;     /* group ID of owner */              dev_t     st_rdev;    /* device ID (if special file) */              off_t     st_size;    /* total size, in bytes */              blksize_t st_blksize; /* blocksize for filesystem I/O */              blkcnt_t  st_blocks;  /* number of blocks allocated */              time_t    st_atime;   /* time of last access */              time_t    st_mtime;   /* time of last modification */              time_t    st_ctime;   /* time of last status change */          };Cela donne déjà pas mal d'information , non ?

lami20j · Answer

Je pense me baser sur les fonctions de dos/windows, parce que ce sont de loin les plus complètes et les plus logiquesfonctions de dos/windows?!Peux tu faire une énumération de ces fonctions les plus complètes et les plus logiques.

lami20j · Answer

Re,la structure donnée dans le message précédent le tiens ne comporte pas le nom de l'élement... ça me semble pourtant fondamental.Pour le nom d'élément c'est normal. stat envoie des infos sur un fichier indiqué (par son nom).Tu peux utiliser opendir, readdir ensembe avec stat,fstat,lstat  pour obtenir ce que tu veux.

hibou57 · Answer

D'ac,donc ça confirme ce que je savais déjà, à part les structure spécifique à dos/windows, il n'existe pas de structure standard réunissant toutes les informations sur un fichier.En fait je cherchais une structure, qui servent d'élément pour un tableau qui représenterais le listing d'un repertoire (c'est pour un client ftp fait maison). Et même si je pouvais bien sure créer ma propre structure, je me disais que si un telle structure existe déjà en standard, alors autant l'utiliser. Ce que je vais donc faire, c'est choisir la structure utilisé par stat, et lui ajouté à la fin, un tableau de caractères pour le nom du fichier. J'aurai quelques chose qui ressemble à la structure utilisé par windows, mais qui ressemblera plus à quelque chose de standard.Le problème qui se pose maintenant, si je ne veux pas délocaliser le nom du fichier (en utilisant un pointeur sur le nom par exemple), c'est de trouver un longueure limite au nom de fichier. Je crois que la limite théorique est de 255 caractères... mais c'est en fait la limite pour la longeur d'une spécification  de chemin absolue... et par conscéquence, celle d'un nom de fichier sans spécification de chemin (même si alors un tel nom de fichier ne pourrait jamais être contenu dans un chemin).Certains système unix sont par contre eux, limité à 32 caractères pour un nom de fichier (si je ne me trompe pas), mais cette limite n'existe pas sous linux (ni sous windows).Je pourrais prendre un valeur raisonnable, comme 64 caractère (parce que je ne vois pas souvent de nom de fichier plus longs, seuls ceux générés automatiquement pour l'enregistrement de page web sont parfois aussi long). Mais en même temps, une telle limite... risquerais toujours d'être dépassé.Ca m'ennuit, mais je crois que ça va être difficile de faire mieux. D'autant qu'à être aussi pointilleux, je vais finir par ennervé du monde, je le sent... je me suis déjà pris la tête avec un artiste qui ne connais rien à la programmation, ici même... je ne fait pas que des ami(e)s lol .Merci encore d'avoir répondu (et c'est vrai, pour l'erreur précédente, j'en ai rie quand tu me l'a fait remarqué).

Aghaster · Answer

Hum... j'avoue que je déplore ce manque de libraire standard moi aussi. Personnellement je programme en C++ en non en C, mais je ne connais pas plus de libraire qui fait le travail. Ça m'intéresse si tu arrives à quelque chose de potable en bout de ligne.-Aghasterwww.planetcpp.info

[ansi C] directory listing

5 réponses

Discussions similaires