Bonjour, je programme sous Visual C++ 6, et dans une fenêtre (MFC) j'ai toute une série de boutons permettant de modifier le nom d'un répertoire, ce qui se fait à l'aide du code ci-dessous.
 

 
Le problème qui se pose est que celà fonctionne très bien sous Windows98, mais que sous XP j'ai toujours le message "Le client n'a pas pu être renommé". Donc il semble que ça bloque au niveau du MoveFile, mais je n'arrive pas à trouver pourquoi (j'ai vérifié, les répertoires ne sont pas en lecture seule)...

Si:
1. tu nous donnais le contenu de repertoire1 et repertoire2 tel que passé à MoveFile.
2. Tu récupérais GetLastError pour nous dire ce qui coince.
3. Tu utilisais std::string ou CString pour gérer tes chaînes de caractères, parce les char toto[1024], ça fait quelques années qu'on en fait plus...
 
Ca serait plus simple à voir...

 
Alors:
1. repertoire1: "c:\Saga\Donnees\ancient nom client", repertoire2: "c:\Saga\Donnees\nouveau nom client"
2. J'ai honte, je n'avais pas pensé au GetLastError...    Donc l'erreur est: "Error 32: Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus". Ce qui est emmerdant c'est qu'il n'y a pas d'autre processus accédant à ce répertoire en même temps, et que le problème n'intervient pas sous 98...
3. Je suis passé au CString depuis quelque temps déjà, mais cette partie du programme est assez ancienne et je n'ai pas eu le temps de modifier les char[] pour les remplacer par des CString...

 
Dans Windows 2000/XP un dossier est considéré comme utilisé par une application son "dossier en cours" pointe dessus (par ex si tu as ouvert un fichier dans ce dossier, il faut que tu quittes l'application qui a ouvert le fichier, que l'application fasse un SetCurrentDirectory sur un autre dossier, ou que tu ouvres un autre fichie).
C'est assez lourd

 
  Ah ok!
Merci beaucoup, je j'avais pas pensé à un truc aussi lourd! Je regardais plutôt du côté de la lecture seule... Et en effet, le dossier en cours pointe directement sur le répertoire que je veux modifier, donc maintenant je sais ce qu'il me reste à faire!

Bon bah, j'avais mis "Résolu" dans le titre, mais je le retire...
 
J'ai essayé plusieurs trucs à base de SetCurrentDirectory pointant sur d'autres répertoires (même un SetCurrentDirectory("c:\\" ), j'ai essayé d'ouvrir un autre fichier, mais rien n'y fait, je me retrouve toujours avec cette saloperie d'erreur32 en cas de MoveFile...

Tu es 100% sûr que tu n'as pas de fichier ouvert dedans (via ton appli), ou l'exploreur qui pointe dessus, ou même un contrôle qui t'affiche le contenu du répertoire ?
 
D'autre part, Win98 avait une gestion plus "légère" des accès concurrents, donc le fait que ça fonctionne dessous ne veut rien dire...

 
les trucs entre crochets faut pas les mettre en début de titre, sinon le nom de la sous-catégorie ne s'ajoute plus automatiquement

 
Oups, désolé...    
 
Et sinon, un conseil pour corriger mon problème?    
(j'ai mis en place un truc bourrin qui passe par du CreateDirectory et du CopyFile, mais ça ne me plait pas du tout...)

T'es sûr que t'as pas un chti handle qui traine sur ton fichier dans ton rep ?
Ou simplement que tu as les droits ?
Lance ton exe mais sans tenter de changer le dir. Pendant qu'il tourne, avec explorer, essaye de changer le nom du dir, pour voir...

 
Pour le handle, je ne crois pas, et j'ai tous les droits nécessaires, mon programme est exécuté soit sur des ordinateurs en local, soit sur un serveur avec les droits complets sur son répertoire.
 
Je vais expliquer de mieux expliquer mon bordel:
J'ai une CListBox que je remplis avec les noms des clients (correspondant chacun à un répertoire) avec la fonction:
 

 
Ensuite, j'ai une fonction OnSelChangeClient() qui affiche les sous-répertoires de ce client et qui est activée dès qu'on clique sur un nom de client dans la CListBox.
 

 
(lister_villes() est comme lister_clients(), sauf qu'on remplit une autre CListBox)
 
A côté de ça, j'ai un bouton permettant de modifier le nom du client sélectionné, dont le code est donné dans mon 1er post.
 
J'ai testé sous l'explorateur, je peux modifier le nom d'un client manuellement, sauf si je le sélectionne au préalable dans la CListBox...
 
J'ai essayé plein de trucs différents, du style faire un SetCurSel(-1) suivi d'un OnSelChangeListeClient() sur la liste des clients juste avant de tenter le MoveFile, ce qui devrait mettre le "focus" de Windows sur un autre répertoire client, mais non, même comme ça il continue de m'afficher que celui que je veux renommer est en cours d'utilisation...
 
Sinon, il y a d'autres fonctions permettant de renommer un répertoire? (enfin à mon avis ça ne fonctionnerait pas mieux, mais on ne sait jamais...)
 
 

Dans mon soft qui renomme des fichiers & dossiers (Ant Renamer) j'utilise MoveFile et je n'ai jamais eu de problème de ce genre...

As tu tester de renommer depuis l'explorer alors que ton soft tourne ?
Sinon lance filemon pour traquer les accès aux fichiers, et process explorer pour lister les handles détenus par ton appli.
http://www.sysinternals.com/ntw2k/source/filemon.shtml
http://www.sysinternals.com/ntw2k/ [...] cexp.shtml

 
Oui j'ai testé, et ça ne fonctionne pas si le client que je veux renommer dans l'explorer est sélectionné dans la CListBox de mon programme.
 
Je vais essayer filemon et process explorer pour voir, merci   !

Donc c'est bien un probleme dans ton code...

 
Ca je m'en doute!    
 
Y a un truc bizarre que je vois apparaître avec Filemon, c'est que j'ai des FindOpen quand je clique sur un nom de client dans la liste (ça c'est normal), mais aucun FindClose! Ce n'est qu'à l'extinction du programme que j'ai une série de Kernel32:FindClose qui apparaît...
C'est bizarre, parce que les seuls accès que je fais aux répertoires se font par "SetCurrentDirectory(repertoire);" ou "handle=FindFirstFile("*.*",&fd);" toujours suivi d'un "FindClose(handle);" ...
 
C'est de là que vient mon problème, non?
 
EDIT: Bon ok, en fait c'est ma fonction de parcours du contenu d'un répertoire qui est mal foutue, il semble que ne je puisse pas faire de FindClose sur un handle qui a pour valeur INVALID_HANDLE_VALUE...   (dit comme ça ça parait logique, mais je n'y avais pas du tout fait attention, surtout que ça paraissait fonctionner)

Bon bah c'était bien ça le problème!
En utilisant le FindFirstFile et le FindClose comme la MSDN le préconise, je n'ai plus ce problème, merci pour votre aide!