explication sur WIN32_FIND_DATA

Version imprimable

05/05/2011, 14h56
poutch

explication sur WIN32_FIND_DATA

Bonjour.

Avant toute chose, je précise que je code avec Visual C++ 2005 express.

Pour les besoin d'un programme, je dois lister le contenu d'un dossier. Après recherches sur internet, j'ai cru comprendre que je devais utiliser FindFirstFile puis FindNextFile. Je suis allé sur le site de Microsoft

FindNextFile

pour le second paramètre il est précisé ceci:

Citation:

A pointer to the WIN32_FIND_DATA structure that receives information about the found file or subdirectory.

donc je me rend ici:

WIN32_FIND_DATA

mais je ne comprends pas plus.

Pourriez-vous m'éclairez SVP ?

merci :)
09/05/2011, 17h03
ctxnop
Salut,
Comme indiqué dans la documentation, le second paramètre est un pointeur vers une structure qui va recevoir les informations sur le fichier.

D'ailleurs il y a un exemple en bas de la documentation de FindFirstFile

Le principe c'est d'instancier une structure de ce type et de passer l'adresse de l'instance à la fonction qui remplira ta structure :
Code:

1 2 3 WIN32_FIND_DATA FindFileData; // la variable qui sera remplie par la fonction HANDLE hFind = FindFirstFile("MonFichier.txt", &FindFileData);
hFind te servira a poursuivre la recherche avec FindNextFile, et il ne faudra pas oublier de terminer la recherche par FindClose.

merci de ta réponse :ccool:

d'après ce que tu m'as dit, j'ai essayé de faire un truc tout simple:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 int main() { WIN32_FIND_DATA FindFileData; HANDLE hFind; hFind = FindFirstFile(L"C:\\Users\\sylvain\\Desktop", &FindFileData); if (hFind == INVALID_HANDLE_VALUE) { cout<<"FindFirstFile failed"+GetLastError()<<endl; } else { cout<<FindFileData.cFileName<<endl; FindClose(hFind); } }
et là, j'ai une suite de caractère en guise de résultat:

Citation:

012FD04

je pensais qu'en précisant cFileName, ça me donnerai le nom du premier fichier trouvé sur le bureau.

10/05/2011, 21h13
ram-0000
Quand je vois :
Code:

1 2 FindFirstFile(L"C:\\Users\\sylvain\\Desktop", ... cout<<"FindFirstFile failed"...
j'ai l'impression que ton programme (et toi aussi) ne sait pas trop s'il est unicode ou pas (et je pense que c'est ton problème).

Donc si tu est en Unicode, TOUTES tes chaines de caractères doivent être en Unicode et l'option de compilation Unicode doit être activée. En unicode, le flux de sortie, c'est st::wcout (et pas std::cout)

Si tu n'est pas un Unicode, cette option doit être désactivée et toutes tes chaines de caractères doivent être "non unicode".

Au fait, n'oublie pas d'activer aussi le niveau 4 pour les warning et erreurs générés par le compilateur, des fois, il y a des messages qui paraissent anodins mais qui cachent un bug.
11/05/2011, 10h07
poutch

je crois que tu viens de soulever une problématique importante x)

je vais réfléchir à çà, et je reviendrai vers toi (enfin, via le sujet) si ça bloque.

en tout cas merci :)
12/05/2011, 16h22
poutch

je pense avoir trouvé la solution à mon problème, mais ça ne marche toujours pas. Et à ce moment là, je tombe sur ça:

Citation:

WIndows 7 problem
This program doesn't work on Windows 7 machine, when trying to get information from a UNIX machine. Works well on Windows XP though.

Or j'utilise Seven ...

ça veut dire, clairement et simplement que je l'ai dans l'os ??
12/05/2011, 18h43
ram-0000
Heu ... j'avoue que je ne comprends pas trop ton message d'erreur.

Décrit un peu mieux ton contexte d'utilisation.
- Ton programme a été compilé sur une machine Windows (quelle version)
- Il s'exécute sur une machine Windows (quelle version)
- Il analyse un répertoire (local ou distant par montage netbios)
12/05/2011, 19h37
ctxnop

Pas compris non plus.
En plus le message dit que ca ne fonctionne pas sous Windows 7 dans le cas où on cherche a obtenir des informations sur une machine UNIX.
Le message laisse supposer que ca fonctionne dans les autres cas, autrement dit si tu n'es pas spécifiquement en train de tenter de parcourir des fichiers a travers un point de montage réseau (samba, nfs, etc...) dont la machine distante est un unix (linux, bsd, macos, aix, etc...), bah ca devrait fonctionner.

désolé pour le précédent message. Après 4h de recherches, je suis tombé sur le message (celui d’incompatibilité avec Seven), ça m'a blasé :mrgreen:

tout ça pour dire que j'ai la solution à mon problème.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 int main() { WIN32_FIND_DATA FindFileData; HANDLE hfind=INVALID_HANDLE_VALUE; hfind = FindFirstFile(L"C:\\Users\\sylvain\\Documents\\*.*", &FindFileData); do { _tprintf(TEXT("%s\n"),FindFileData.cFileName); } while(FindNextFile(hfind,&FindFileData)!=0); FindClose(hfind); }
j'ai compris une chose (très) importante: dans la variable qui contient le chemin du dossier, pour qu'on puisse tout afficher il faut préciser "chemin\*.*"
C'est couillon dis comme ça, mais qu'on on sait pas :lol:

en tout cas, merci à tous pour votre aide.

12/05/2011, 21h36
ram-0000
Cela manque encore de cohérence dans tes chaines de caractères :
Code:

1 2 FindFirstFile(L"C:\\Users\\sylvain\\Documents\\*.*", _tprintf(TEXT("%s\n"),FindFileData.cFileName);
- la lettre L signifie (dans ce contexte) signifie que ta chaine de caractères est UNICODE seulement.
- La macro TEXT signifie que ta chaine de caractères est UNICODE ou ANSI suivant le mode de compilation de ton projet (Unicode ou non Unicode). Les macro TEXT, _TEXT et _T sont équivalentes.
Le fait d'utiliser TEXT rend ton code plus adaptatif à l'environnement de développement.
Le fait d'utiliser la lettre L force ton code à fonctionner en mode Unicode.

En général, on fait un choix et on tente de s'y tenir, sinon, cela fait des problèmes à n'en plus finir.
16/05/2011, 20h45
poutch

merci de ces précisions.

pour être honnête, l'encodage des caractères n'est pas une notion que je gère bien. Je me suis rendu compte que lorsque j'effectuais le parcours de mes dossiers (donc avec la fonction précédemment citée), mes "é" apparaissaient en "ù". Donc je vois bien qu'il y a un problèmr. Mais je en sais pas vraiment à quel moment, et je pense que les problèmes sont multiples.Du même style de ce que tu m'as montré, mais présent dans l'intégralité de mon code.

je vais essayer d'y faire attention, et de corriger les problèmes déjà existant.

en tout cas merci
17/05/2011, 00h47
ctxnop

Citation:

Envoyé par poutch

j'ai compris une chose (très) importante: dans la variable qui contient le chemin du dossier, pour qu'on puisse tout afficher il faut préciser "chemin\*.*"
C'est couillon dis comme ça, mais qu'on on sait pas :lol:

en tout cas, merci à tous pour votre aide.

En fait, la documentation dit :

Citation:

Envoyé par msdn

lpFileName [in]

The directory or path, and the file name, which can include wildcard characters, for example, an asterisk (*) or a question mark (?).

This parameter should not be NULL, an invalid string (for example, an empty string or a string that is missing the terminating null character), or end in a trailing backslash (\).

If the string ends with a wildcard, period (.), or directory name, the user must have access permissions to the root and all subdirectories on the path.

In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 widecharacters, call the Unicode version of the function and prepend "\\?\" to the path. For more information, see Naming a File.

Autrement dit, si tu recherche les fichiers présents dans C:\Mon\Chemin, le chemin a spécifier est C:\Mon\Chemin, et non C:\Mon\Chemin\.
Utiliser *.* n'est pas véritablement une bonne idée, cela signifie que tu recherche des fichiers ayant un nom et une extension, ce qui n'est pas le cas de tous les fichiers. Par exemple, il existe beaucoup de fichiers qui n'ont pas d'extention (notamment sous unix) et d'autres tels que ".htaccess", qui n'a pas de nom, mais juste une extention. Tout ces fichiers ne seront pas trouvé en utilisant *.*
Si le coup d'omettre le trailing backslash n'est pas suffisant et que tu es contraint d'utiliser un wildcard, utilise uniquement '*', ca signifie "tout et n'importe quoi", donc tout passera.
24/05/2011, 11h10
Médinoc

Je crois qu'il y a un des deux OS (Windows ou *n*x, et je crois bien que c'est Windows) où le code prend exprès en considération ce cas de figure, forçant "*.*" à tout trouver.

Bonjour/Bonsoir,

Je sais que la discussion est résolue mais j'ai le code suivant:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 WIN32_FIND_DATA File; HANDLE hSearch; hSearch = FindFirstFile(L"c:\\*", &File); if (hSearch != INVALID_HANDLE_VALUE) { do { printf("%ws\n", File.cFileName); } while (FindNextFile(hSearch, &File)); FindClose(hSearch); } return 0;
Je souhaiterais pouvoir faire en sort qu'il me liste également les sous dossiers contenus dans les dossiers trouvé. Auriez vous une idée à me proposer ou un bout de code?
Je vais continuer à chercher sur le net. Mais je pose déjà la question ;) ;) ;) ;)

Merci d'avance.

Vous avez testé votre code ?
Parce que moi oui, je l'ai juste très légèrement ré-écris, mais sans changer le fonctionnement et il me liste bien les sous-répertoires :

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
#include <iostream>
#define WIN32_LEAN_AND_MEAN
#define VC_EXTRALEAN
#include <windows.h>
 
#if UNICODE
#define TOUT std::wcout
#else
#define TOUT std::cout
#endif
 
int main(int argc, char** argv)
{
 
    WIN32_FIND_DATA f;
    HANDLE hSearch;
 
    hSearch = ::FindFirstFile(TEXT("c:\\*"), &f);
    while (hSearch != INVALID_HANDLE_VALUE)
    {
        TOUT << (f.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY ? TEXT("DIRECTORY - ") : TEXT("FILE - ")) << f.cFileName << std::endl;
        if (!::FindNextFile(hSearch, &f))
        {
            ::FindClose(hSearch);
            hSearch = INVALID_HANDLE_VALUE;
        }
    }
    return 0;
}

08/01/2017, 14h12
Médinoc

Anubisas demande probablement à faire une recherche récursive, en fait.
C'est un peu compliqué, mais on peut éviter la récursivité si on utilise un conteneur (par exemple une file) pour faire un parcours en largeur de l'arborescence... (j'ai trouvé cette idée dans un code de Microsoft)
08/01/2017, 16h55
Anubisas

Merci de vos deux réponses.

ctxnop, j'ai testé les ligne de code mais je n'ai pas réussi à le modifier pour faire ce que je souhaite. Je vais essayer ton code ce soir.

Médinoc, tu as bien raison. En effet, je compte faire un listing complet du disque dur via un recherche récursive. Aurais tu un exemple de cette méthode.

Citation:

mais on peut éviter la récursivité si on utilise un conteneur (par exemple une file) pour faire un parcours en largeur de l'arborescence... (j'ai trouvé cette idée dans un code de Microsoft)

Saurais tu me donner l'adresse de cette exemple, car même si je veux connaitre la solution sans le conteneur, je suis preneur du dit exemple.

En tout les cas, merci à vous deux de vos réponses et merci à tout les personnes qui ont répondu sur ce post car cela m'aide quand même bien.
08/01/2017, 17h12
ctxnop

Je me doute bien que le but est une recherche récursive, je voulais juste pas donner une soluce toute faite.
Le code que je donne permet de faire la différence entre un répertoire et un fichier. Il suffit alors de faire une fonction récursive qui, quand elle trouve un dossier, se ré-appelle elle-même avec ce dossier pour point de départ. Bref, il n'y a que la récursivité à ajouter...
08/01/2017, 17h16
Anubisas

Désoler pour le double post, j'ai voulus éditer mon précédent et je me retrouve avec une page blanche me disant "page no found"?!?

Enfin, ce n'est pas grave. Je viens de tester votre code ctxnop, il fonctionne bien. Mais ce n'est que pour me dire qui est un fichier et qui est un dossier. C'est très pratique tout de même, j'avoue ;)

Cependant, je souhaite faire une fonction récursive qui me listera tout les dossiers et les fichiers sur le disque dur. Je vais donc essayer de voir la solution de Médinoc qui me semble être la bonne.

En attendant d'avoir le lien en question, je vais faire mes petites recherche en me basant sur son message.

Merci encore de votre aide qui m'est extrêmement précieuse.

Amicalement, Frédéric.