Discussion :

[rothuswarrior]

Bonjour,

je code actuellement sous Visual C++ Express 2010.
Je cherche à compter le nombre de fichiers qu'il y a dans un dossier sous c:\Windows\System32\winevt.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
  std::string folderPath = "C:\\Windows\\System32\\winevt\\Logs"; 
 
  WIN32_FIND_DATAA findData;
  HANDLE hFind = INVALID_HANDLE_VALUE;
 
			std::string searchPath = folderPath + "\\*";
			hFind = FindFirstFileA(folderPath.c_str(), &findData);
 
			if (hFind == INVALID_HANDLE_VALUE) 
			{
				 std::cout << "Erreur lors de l'ouverture du dossier." << std::endl;
        	 }
 
			int Compteur = 0;
 
			do 
			{
				if (!(findData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)) 
				{
					Compteur++;
				}
			} 
			while (FindNextFileA(hFind, &findData) != 0);
 
			FindClose(hFind);
 
			std::cout << "Nombre de fichiers dans le dossier : " << Compteur << std::endl;

Le problème c'est que hFind ne vaut rien, ne retourne rien (0xFFFFFF). Si je mets folderPath = "C:\Windows\Dossierxxx", ca fonctionne très bien.
Est-ce qu'il y a des soucis avec les droits ou quelque chose du genre ??

Merci d'avance pour votre aide.

[jesse100]

Le problème que vous rencontrez avec la valeur hFind renvoyant INVALID_HANDLE_VALUE (0xFFFFFF) peut être dû à un problème avec le chemin du dossier ou les autorisations. Pour résoudre le problème, assurez-vous que le chemin du dossier que vous utilisez (C:\Windows\System32\winevt\Logs) est correct et que toutes les barres obliques inverses sont correctement échappées dans le code (\\ au lieu de \). De plus, le dossier C:\Windows\System32 est un dossier système avec un accès restreint par défaut, assurez-vous donc que vous disposez des autorisations suffisantes pour y accéder.

Essayez d'exécuter votre programme avec des privilèges d'administrateur élevés en cliquant avec le bouton droit sur Visual Studio ou sur l'exécutable compilé et en sélectionnant "Exécuter en tant qu'administrateur". Une autre option consiste à exécuter Visual C++ Express 2010 lui-même en tant qu'administrateur.

Si le problème persiste, envisagez d'utiliser un dossier différent comme test pour déterminer s'il est spécifique au dossier C:\Windows\System32 ou à un problème plus général. Pour recueillir plus d'informations sur l'erreur, vous pouvez ajouter un code de gestion des erreurs à l'aide de la fonction GetLastError, qui vous fournira un code d'erreur pouvant aider à identifier le problème spécifique. N'oubliez pas de faire preuve de prudence lorsque vous accédez aux dossiers système et exécutez toujours votre code avec les autorisations appropriées.

[rothuswarrior]

Merci pour ta réponse.
En fait j'ai fini par trouvé d'ou venait le problème. Avec Visual c++ 2010 express, l'appli est en 32bits, or le dossier System32 est sur un Windows 64bits, d'où le souci.
J'ai rajouté le code suivant.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
	if( Wow64DisableWow64FsRedirection(&OldValue) ) 
			{
 
				StringCchCopy(szDir, MAX_PATH, TEXT("C:\\Windows\\System32\\Winevt\\Logs"));
				StringCchCat(szDir, MAX_PATH, TEXT("\\*.*"));
 
				hFind = FindFirstFile(szDir, &ffd);
			}

Ainsi ca fonctionne beaucoup mieux.

Mais merci quand même pour ton message.

[bacelar]

Vous avez une vue un peu trop "simpliste" du "problème".

Votre approche est un peu foireuse.

Concrètement, vous avez désactivé une astuce pour qu'une application 32bits ait des chances raisonnables d'encore fonctionner dans un OS 64bits.

Vous vous trompez sur la cause du problème, sur les moyens les plus sûrs de régler le problème, sur le périmètre des changements de comportement induits, sur la mise en oeuvre de la "solution" que vous tentez d'implémenter.

En résumé, @jesse100 est bien plus proche d'une solution "safe" que votre bidouillage.

Si vous pensez que tous les threads vont, par magie, désactiver la redirection, vous vous trompez, seul le thread actif aura cette désactivation.
Si votre thread a l'idée "stupide" de charger/attacher une dll pendant la désactivation, vous êtes dans une m.... noire.
Il n'y a pas de que "System32" qui est redirigé.
etc...

En bref, RTFM (et comprenez le, l'exemple est pile-poil dans votre cas mais ne fait pas les énormes bourdes du code qui vous avez posté) :
https://learn.microsoft.com/fr-fr/wi...4fsredirection

Mais pourquoi utiliser une API aussi vieille (Win32, c'est du millénaire dernier, sans exagération), c'est pas portable (Windows Only), quand il existe une API portable, et standard depuis 2017 :
https://en.cppreference.com/w/cpp/fi...ctory_iterator

Comme c'est une vieille API, ce que propose @jesse100 est loin d'être stupide, si vous ne les appliquer pas, votre bidule plantera sans vous donner la moindre info.
C'est une API C, il faut donc systématiquement vérifier les codes retours et utiliser SYSTÉMATIQUEMENT GetLastError pour le traitement des codes retours en erreur.

La source du "problème" n'est pas lié à "Visual c++ 2010 express", en aucun cas.

La source initiale, c'est votre ignorance sur le fait que chargeur de l'OS configure le processus pour qu'un applicatif 32bits se croit dans un OS 32bits.

Mais bon, qui fait un applicatif 32bits en 2023 ???

EDIT :

Client minimal pris en charge Windows Vista, Windows XP Professional x64 Edition [applications de bureau uniquement]

J'ai été un peu loin pour le millénaire dernier, l'API est de WinXP (2001), c'est "juste" 22 ans (, ou ~20 si c'est Windows Server 2003 avec SP1 qui l'introduit, si XP x64 Editions sont plus récentes que Windows Server 2003 avec SP1).

Petite question pour les spécialistes des autres OS, comment la gestion des applications 32bits est effectuée dans les autres OS 64bits, SVP ?

[rothuswarrior]

Salut Bacelar,

En fait, je cherche à copier certains fichiers evt (des archives plus précisément), pour les déplacer dans un autre dossier (un dossier de sauvegarde), puis de les supprimer dans le dossier d'origine.

Dans Visual c++ 2010 express, je n'ai pas d'autres choix que de faire en 32bits.
J'ai également essayé avec visual 2015, mais lors du build en 64bits, il me sort un message ''LINK : fatal error LNK1561: entry point must be defined'', et je reste donc bloqué la-dessus car je n'ai trouvé aucune solution pour le moment pour regler ce souci de lnk.


J'ai également essayé avec ton API portable, standard

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 std::ifstream source(DossierSource, std::ios::binary);

mais ici aussi, ''source'' ne vaut rien. DossierSource est bien réél, bien valide,....

Quand je test avec des dossiers tests (Dossier1 = dossier source, Dossier2 = dossier destination, les 2 à la racine), ca fonctionne nikel.

Je suis preneur de toutes les idées me permettant d'avancer.

Merci d'avance.

[Bousk]

Est-ce pertinent de vouloir faire ça en C++, en concaténant les chaînes de caractères en C, quand on débute avec le langage et utilises un IDE obsolète ?
Déplacer des fichiers c'est 1 ligne de bat avec MOVE ?

[rothuswarrior]

Salut Bousk,

Je voulais faire une jolie interface, avec une progressbar pour bien présenter tout çà.

J'ai suivi ton conseil, et fait un .bat. Ca fonctionne nikel.

Merci pour ton idée.

cdt,

[Christophe]

comment la gestion des applications 32bits est effectuée dans les autres OS 64bits, SVP ?

Sous Linux, au niveau du code en C, aucun changement, le nom des fonctions ne change pas. Il faut recompiler en 64 bits ou avoir installé les bibliothèques 32 bits pour pouvoir utiliser du code 32 bits. Si tu installes un logiciel 32 bits, le gestionnaire de paquets installera les bibliothèques nécessaires (gestion des dépendances géré dans le paquet). les libc 32 et 64 bits cohabiterons.

Au niveau de l'emplacement des bibliothèques, tu auras /lib, avec lib64 vs /lib32 selon la distro. Sans parler de /usr/lib.

L'emplacement par défaut des bibliothèque est normalisé mais tout comme sous Windows pas forcément respecté. (c'est quand-même moins le bordel que sous Windows mais c'est plus un prob de developpeur que d'OS)

Sous Windows tu as plusieurs API, win32, UWP qui peuvent cohabiter.

Sur MacOS, à partir de Mac OS Catalina, qui date maintenant de 2019 aucune application 32 bit ne peut être exécuté. Il faut ajouter à cela que maintenant Apple n'utilise plus les processeurs Intel. Les anciennes applis Intel peuvent toujours être utilisé avec les nouveaux CPU Apple M1 et M2 de type ARM via l'émulateur fourni : Rosetta2 qui fait très bien le job.

Depuis Windows 11, il n'y a plus de version 32 bits de l'OS, Intel parle de supprimer la gestion 32 bits dans ses futurs CPU et donc la rétrocompatibilité (au moins en partie, ne plus démarrer en mode réel et passer ensuite en 64 bits comme c'est encore le çà ne signifie pas forcément que les registres CPU ne seront plus adressables en 32 bits, et il y aura toujours la virtualisation/l'émulation)

[bacelar]

Merci pour vos réponses, @Bousk et @chrtophe.

@Bousk, ta remarque est efficace, mais on a quand même échappé au classique copie du contenu du fichier par une boucle sur un buffer de 1024 caractères alloué dans la stack.

Ma réponse était plus axée sur le fait d'utiliser des IDEs/APIs/librairies plus récentes et plus simple d'utilisation, plutôt que d'utiliser des vieux clous.

@rothuswarrior, VS2015 c'est un vieux clou à peine moins rouillé que VS2010.

''LINK : fatal error LNK1561: entry point must be defined'

Ca sent le projet mal configuré. (Outils de migration foireux ?)

Commencez avec un projet VS "vierge compilable" puis ajoutez s'y votre code.

mais ici aussi, ''source'' ne vaut rien. DossierSource est bien réél, bien valide,....

Vous n'avez donc pas compris ma réponse, car ce que vous écrivez n'a aucun sens "dans l'absolu".

De plus, vous essayez de lire le "contenu" d'un répertoire, ce qui, aussi, n'a aucun sens.
Un fichier a un flux d'octets (ou plusieurs s'il utilise des "channels") en guise de contenu, mais un répertoire n'a pas de "contenu".
Quand on dit qu'un répertoire contient des sous-répertoires et des fichiers, c'est un abus de langage.

C'est pour cela qu'il y a la classe "std::filesystem::directory_entry" (https://en.cppreference.com/w/cpp/fi...irectory_entry) qui n'est ni un "std::ifstream" ni un "std::FILE".

Il est assez probable que vous ayez spécifié des chemins vers les répertoires de manières "non standard" (avec des séparateurs de nom "\" au lieu du séparateur "/" standard, etc...).

Utiliser les "nouveaux" outils demande un peu de recul.

@chrtophe, si je comprends bien, sous Linux, ça marche un peu comme sous Windows, où le chargeur de l'OS fait en sorte que "/lib" et "/usr/lib" pointent vers "/lib64" et "/usr/lib64" si l'en-tête du fichier exécutable (toujours au format ELF ?) indique un exécutable 64bits et vers "/lib32" et "/usr/lib32" sinon ?
(Reste le pilotage du runtime C qui n'est pas implémenté dans une lib mais directement dans le kernel ? => patch de la table des appels systèmes ?)

[Christophe]

Quand je disais que sous Linux, ça marche un peu comme sous Windows, je voulais dire qu'il y a des emplacement officiels mais qu'il est possible de mettre des bibliothèques partagées ailleurs. C’est quand même moins le bordel que sous Windows car le gestionnaire de paquet sait ce qui a été installé et ou et sais si une autre appli l'utilise ou non (et dans ce cas pas de suppression). Et par défaut si une bibliothèque n'est pas recherchée dans le dossier de l'appli comme sous Windows. On peut indiquer par la variable d’environnement LD_PRELOAD un chemin prioritaire de chargement.

Sur une Debian de base que j'utilise par exemple, les bibliothèques sont dans /lib64 et j'ai le chargeur ld-linux dans /li, lien symbolique vers le fichier réel dans /lib64.

Pour l'histoire /lib /usr/lib /lib est normalement réservé aux bibliothèques essentielles au fonctionnement du système (en gros les applis dans /bin et /sbin sont sensé cherhcer leur biblioth_èques partagées dans /lib), /usr/lib pour les bibliothèques des applis (binaires dans /usr/bin et /usr/sbin). Tu as aussi /var/lib qui est le pendant en lecture-écriture de /usr/bin ou là ça va être pas mal le bordel (enfin si c'est mal géré par les programmeurs d'appli comme sous Windows), ça va être l’équivalent de programdata. Pour la libc, les applis 64 bits chargeront la version 64 bits, les 32 bits la version 32 bits.