7
votes

FileExists () renvoie false, même si le fichier existe

Je veux vérifier si une DLL dans le répertoire System32 (Windows 7) existe. Mais même si cela existe, les FileExists () renvoie false. LoadLibrary renvoie une poignée valide. Dans ce cas, je veux seulement vérifier, si les fichiers existent et visualisent ces informations. Avez-vous des conseils pour résoudre ce problème?


2 commentaires

Je suppose que "autorisations" problème. Vista / Windows 7 est très protecteur à propos de laisser les gens boue dans \ Windows :)


@ Paulsm4: Non, ça ne peut pas être ça. Windows vous permettra toujours de savoir si un fichier existe ou non.


4 Réponses :


10
votes

Pas beaucoup d'informations à partir, le code que vous utilisez peut aider, mais cela pourrait-il s'agir d'un problème de 64 bits et que la DLL est en fait dans le dossier SYSWOW64? Voir Voici pour une bonne description de la façon dont cela fonctionne.


0 commentaires

2
votes

Vous ne spécifiez presque certainement pas le chemin relatif complet ou valide du fichier dans votre FileExists appel. LoadLibrary recherchera certains emplacements (ceux où les DLL devraient résider) pour vous, mais FileExists ne sera pas. Fournissez le chemin complet et correct et FileExists fonctionnera correctement.


0 commentaires

21
votes

Très probablement, il s'agit d'une redirection de fichier. Vous avez une machine 64 bits mais à partir du 32 processus Delphi, Windows \ system32 redirige en Windows \ sswow64 . Ainsi, lorsque vous pensez que vous demandez l'existence d'un fichier dans Windows \ system32 , le système rapporte en réalité l'existence (ou autrement) d'un fichier dans Windows \ sswow64 .

Si vous avez vraiment besoin de voir dans le TRUE 64 bits System32, vous devez désactiver la redirection de fichier. Vous pouvez le faire avec le < Code> WOW64DISABLEWOW64FSRECTION () fonction. N'oubliez pas de le basculer avec WOW64REVERTWOW64FSRECTION () . Méfiez-vous que la désactivation du redirecteur a une large portée et peut entraîner un comportement très étrange ainsi avec soin.


6 commentaires

C'est plus comme ça. (Eh bien, ceci et un type idiot, bien sûr ...)


Maintenant que j'y pense, je suis 99% c'est le problème. +1, définitivement.


Oui, probablement c'est le cas, dans le passé, j'avais quelque chose de similaire, l'étrange était que mon commandant total m'a montré le dossier redirigé, après que quelqu'un m'a dit que c'est parce que tout est clair. (Vous pouvez toujours désactiver la redirection ). Quoi qu'il en soit, il suffit de vérifier le site TC, il y a maintenant une bêta de 64 bits.


Vous pouvez utiliser l'alias spécial «snsnatif» pour accéder au dossier System32 64 bits sans désactiver la redirection du système de fichiers, par exemple: FileExists ('C: \ Windows \ Sysnative \ FileName.dll')


@Remy C'est un bon point, mais si vous souhaitez prendre en charge XP 64, vous devez vous assurer que le correctif correspondant est installé.


@David: S'il tente d'accéder à un fichier réel dans "C: \ Windows \ System32" sur un système 64 bit afin de charger la bibliothèque , il pourrait en réalité Selon le sens que ne devrait pas travailler, car le fichier est très probablement un dll 64 bits .



1
votes

C'est la raison la plus ridicule, mais si cela peut aider une seule personne ...

Assurez-vous de ne pas nommer accidentellement le fichier quelque chose.dll.dll .

Je viens d'avoir une situation où j'ai installé une application sur un ordinateur client, puis l'application n'a pas pu trouver config.txt dans le même répertoire. Cela fonctionnait bien sur d'autres ordinateurs, alors bien sûr, j'étais coupé.

active le paramètre "Afficher les extensions de fichier" a été désactivé sur cet ordinateur client, et le fichier avait été nommé config.txt.txt ... dans ma défense, je passe 90% du temps sur OSX et 9,99% sur mon propre système Windows, avec "Expositions de fichiers" activés depuis il y a longtemps.


0 commentaires