Problème avec readdir de dirent.h

Bonjour,

J'aimerai comprendre pourquoi ce code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

int main(int argc, char *argv[]) { DIR *dossier = NULL; dirent *ent = NULL;   dossier = opendir("/home/flynet/Bureau/dossier2"); if(dossier != NULL) { while((ent=readdir(dossier)) != NULL) printf("%s\n", (ent->d_name));   closedir(dossier); }   return 0; }

---

me renvoie cela :
.
dossier2
dossier
..
fichier

Je ne devrai pas avoir plutôt le '.' en premier puis le '..' en deuxièmre position ? Ce qui est curieux c'est que dans un dossier comme Documents, il me donne le bon ordre.

Si quelqu'un pouvait m'expliquer ce qui coche, je lui en serait reconnaissant !

quelles librairies utilises-tu?

Rien, dans la documentation de opendir ou de readdir, du moins sous Linux, n'est dit sur l'ordre dans lequel tu récupères tes fichiers donc tu ne dois rien présumer.

Et d'ailleurs, quel serait le "bon" ordre ?

Bonjour,

j'utilise les bibliothèques standards avec dirent.h et sys/types.h.

Sinon je pensais que le dossier courant '.' devait être le premier suivi du dossier précédent '..', du moins un peu comme 'ls'.

Mais ls les affiche dans un ordre donné et, visiblement, pas dans l'ordre où il les récupère :

Code:

---

1 2	List information about the FILEs (the current directory by default). Sort entries alphabetically if none of -cftuvSUX nor --sort.

---

C'est plus qu'une écriture à la volée que ls effectue : il trie ce qu'il récupère avant d'afficher. Certaines options (je ne les ai plus en tête) permettent de modifier cet ordre.

Bon si je comprends bien readdir n'est pas sensé commencé par les dossiers '.' et '..'.

J'aimerai comprendre pourquoi quand j'utilise telldir celui-ci me renvoie un nombre normal alors que sur un tuto que j'ai trouvé sur Internet,
on dit que sur les systèmes unix on a des chiffres faramineux pour telldir ?

Ensuite pourquoi quand je me positione avec seekdir(dossier, 2), celui-ci me renvoie les fichiers dans le même ordre et donc à partir du 1er élèment ? par exemple j'obtiens cette liste que ce soit avec seekdir ou pas.
fichier.txt
.
headers
..
sources
prog


Dernière question, est-ce dirent.h propose une fonction pour lire la taille d'un dossier ?

Citation:

---

J'aimerai comprendre pourquoi quand j'utilise telldir celui-ci me renvoie un nombre normal alors que sur un tuto que j'ai trouvé sur Internet,
on dit que sur les systèmes unix on a des chiffres faramineux pour telldir ?

---

Je récupère aussi des valeurs élevées, exceptée la valeur particulière (0) pour le répertoire courant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

plx@sony:~/rep$ ls seekdir seekdir.c plx@sony:~/rep$ more seekdir.c #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <dirent.h>   int main(int argc, char *argv[]) { DIR *dossier; struct dirent *ent; long offset;   dossier = opendir(argv[1]); offset = telldir(dossier); while((ent=readdir(dossier)) != NULL) { printf("%3ld : %s\n",offset,(ent->d_name)); offset = telldir(dossier); }   fprintf(stdout, "offset : "); fscanf(stdin,"%ld",&offset); seekdir(dossier,offset); ent = readdir(dossier); printf("%3ld : %s\n",offset,(ent->d_name));   closedir(dossier); } plx@sony:~/rep$ ./seekdir . 0 : . 871840692 : seekdir.c 1122910076 : .. 1410596373 : seekdir offset : 0 0 : . plx@sony:~/rep$ ./seekdir . 0 : . 871840692 : seekdir.c 1122910076 : .. 1410596373 : seekdir offset : 1410596373 1410596373 : seekdir plx@sony:~/rep$

---

Citation:

---

... seekdir(dossier, 2)

---

Un offset à 2 me parait assez improbable. Tu as du te planter quelque part

Citation:

---

Dernière question, est-ce dirent.h propose une fonction pour lire la taille d'un dossier ?

---

Qu'entends-tu par "taille d'un dossier" ? Nombre de fichiers ou "taille disque" ?

Si c'est la taille disque, un fstat doit faire l'affaire. Sinon, scandir sans filtre te renverra le nombre "d'entrées" récupérées. Scandir doit pouvoir aussi te premettre de récupérer les noms dans le "bon" ordre en spécifiant la fonction de comparaison (un peu à la qsort)

Oui en fait ce qui m'a perturbé et qui me perturbe encore c'est le '0', avec ton code j'obtiens :
flynet@flynet-desktop:~/Bureau$ ./prog1 prog
0 : vista_64bit.iso
763111548 : .
1270425853 : header
1512223833 : ..
1515707672 : sources
1984510484 : prog

Or quand je place telldir juste après le readdir j'obtiens :
763111548 : vista_64bit.iso
1270425853 : .
1512223833 : header
1515707672 : ..
1984510484 : sources
2147483647 : prog

Il faut donc placer le telldir après readdir ?

Citation:

---

... avec ton code j'obtiens ...

---

où sont les lignes où tu saisis une valeur d'offset pour vérifier la cohérence générale (et le bon usage du seekdir et telldir) ? Tu as fait un copier-coller partiel ? Ou c'est, à vue de nez, que tu considères que ce que tu as écrit est équivalent à ce que j'ai posté ?

Si tu utilises vraiment le code que j'ai posté, tu devrais pouvoir "expérimentalement" trancher sur le bon ordre entre le telldir et le readdir.

Et sinon, fais l'analogie avec des ftell/fread classiques : si tu fais un ftell après avoir lu quelque chose, tu ne peux pas associer l'offset retourné à ce que tu as lu ! Si tu y reviens avec un fseek tu te placeras ... derrière !


ps : pour info, sous MacOSX (basé sur FreeBSD il me semble), le code réellement posté en #7, sans changement, tout pareil, juré promis, donne ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

mac0908mt070:tmp pascal$ ../seekdir . 0 : . 1 : .. 2 : .DS_Store 3 : DMED 4 : DTED 5 : GAZETTE 6 : LIBRARY 7 : README.HTM 8 : TEXT 9 : VOL_LIST.DIM 10 : VOL_LIST.XSL offset : 4 4 : DTED mac0908mt070:tmp pascal$

---

Etonnant, non ?

Bonjour,

Oui j'ai pas eu le temps de bien testé ton code, la je viens de faire plusieurs essais.
Voici le résultat en commentant le premier telldir(donc en ayant le telldir après le readdir) :

Code:

---

1 2 3 4 5 6 7 8 9 10

flynet@flynet-desktop:~/Bureau$ gcc example.c -o prog1 flynet@flynet-desktop:~/Bureau$ ./prog1 prog 8126656 : vista_64bit.iso 763111548 : . 1270425853 : header 1512223833 : .. 1515707672 : sources 1984510484 : prog offset : 8126656 8126656 : vista_64bit.iso

---

là en commentant le 2e telldir :

Code:

---

1 2 3 4 5 6 7 8 9 10

flynet@flynet-desktop:~/Bureau$ gcc example.c -o prog1 flynet@flynet-desktop:~/Bureau$ ./prog1 prog 0 : vista_64bit.iso 0 : . 0 : header 0 : .. 0 : sources 0 : prog offset : 0 0 : vista_64bit.iso

---

Or ce code ci, si je mets n'importe quel petit nombre au hasard(1, 2, ... y compris 0), je retombe toujours sur le vista_64bit.iso.

Ce qui se retrouve avec ton code initial. Je pense donc que le telldir doit être placé après le readdir.

Non !!!

Si tu veux associer (comme le fait mon exemple en #7) un offset à quelque chose dans un fichier, tu dois d'abord récupérer la position courante puis lire ce que tu as à lire pour associer l'offset à ce qui est lu, pour pouvoir y revenir ensuite.

Prends l'exemple d'un fichier tout bête : le tout début du fichier doit bien être associé à l'offset 0, non ? Si, dès l'ouverture du fichier (mode r), tu lis quelque chose et que tu fais un ftell, tu récupèreras un offset non nul alors que c'est évident qu'il faut associer 0 !

Donc, dans mon exemple, il n'y a aucun telldir à commenter.
Le premier est nécessaire car j'écris une boucle while dont la condition porte sur le résultat du readdir. Donc, je suis bien obligé de faire un telldir avant.

Le deuxième est lui aussi nécessaire (il est fait avant le readdir suivant) et est exécuté à chaque itération. Le dernier résultat (dernier offset) n'est pas affiché (il correspond à la "fin de répertoire"), c'est tout.

Ah !!! Oui je comprends ce que tu veux dire ! Je sais vraiment pas ce qui m'a pris mais je suis me forcer dans une mauvaise direction ...

Merci de ton aide !