Discussion :

[ron_60]

Bonjour j'ai un soucis sur la notification de windows. J'utilise la fonction FindFirstChangeNotificationW en profondeur 0, jusqu'à la pas de soucis.

Le code correspondant :

dwChangeHandles[dwWaitStatus] = FindFirstChangeNotificationW(

(WCHAR*)QString(
QDir::toNativeSeparators (this->directory[dwWaitStatus-1])+"\\").utf16(), // directory to watch
FALSE, // do not watch the subtree

FILE_ACTION_MODIFIED
| FILE_NOTIFY_CHANGE_DIR_NAME
| FILE_NOTIFY_CHANGE_FILE_NAME
| FILE_NOTIFY_CHANGE_SIZE
| FILE_NOTIFY_CHANGE_LAST_WRITE
| FILE_NOTIFY_CHANGE_ATTRIBUTES

);


Mon problème survient quand je fais autre notification dans un sous dossier. Je n'arrive plus à detruire le dossier.

Un exemple veux mieux:

Je notifie c:\test, c:\test\photos et c:\test\musics.
Je ne peut plus supprimer ni renommer le dossier "c:\test". Par contre je peux renommer photos et musics.

Je ne sais pas comment résoudre se problème. Par contre je me demande s'il n'y a pas une notification windows juste avant le renommage ou un destruction spécifique.

Ou serait-il mieux utiliser l'option subtree de windows, mais là comment savoir où vient la notification

[ron_60]

Apparament il y a peu etre la solution FileSystemWatcher, j'ai demandé à plusieurs personne si ca pouvait résoudre mon probleme j'attends le mp .

[ron_60]

Arf je me fais un monologue
Bon FileSystemWatcher, m'a pas l'air d'etre une bonne notification. C'est une fonction qui a l air de regarder toute les secondes si le dossier à changer. Donc si on à 2000 dossiers ca rame

[Melem]

Ce n'est pourtant pas surprenant. Un dossier ou fichier ne peut pas être supprimé ou renommé pendant qu'il est encore ouvert (ouvert veut dire : une application l'utilise ou encore : il y a un handle ouvert sur ce dossier ou fichier quelque part). FindFirstChangeNotification surveille les changements qui se passent à l'intérieur du dossier spécifier mais ne surveille pas les changements sur le dossier lui-même qui, lui, est encore ouvert. Tant que ce dossier reste ouvert, tu ne pourras pas le supprimer.

... j'ai demandé à plusieurs personne si ca pouvait résoudre mon probleme j'attends le mp

Attention. Les MPs ne sont pas faits pour les questions techniques. Pour ça, il y a le forum. Lire les règles du forum.

[ron_60]

Pour toutes les notifications en bouts d'arbre peuvent être renommé et supprimé.


Un exemple simple

c:\mon dossier
c:\mon dossier\photos
c:\mon dossier\photos\anniversaire 2004
c:\mon dossier\photos\anniversaire 2004\trombinoscope

Ses dossiers sont tous notifiés.
Je remarque que :

• je ne peux pas supprimer ni renommer "c:\mon dossier"
• Je peux renommer et detruire trombinoscope, alors qu'il est notifié.
• Quand je demande la destruction de "c:\mon dossier". La premiere fois il supprime uniquement "c:\mon dossier\photos\anniversaire 2004\trombinoscope", la deuxieme fois "c:\mon dossier\photos\anniversaire 2004", la troisieme fois c:\mon dossier\photos, et la quatrieme fois "c:\mon dossier".

Donc d'apres ce que je comprends, un dossier ne peut pas être supprimé ou renommé s'il contient directement une autre notification. Je n'ai pas verifie si c'etait indirect.

Je commence à me demander si je vais pas faire une solution un peu batard, avec une solution de notification en bout de branche. Et pour le milieu une notification general "subtree" et de chercher quel dossier à été modifié.

Ou de faire le contraire de faire un notification normal à la racine (ici:c:\mon dossier) . Et faire des notifications generals avec option subtree et de chercher ou le changement a été effectué.

[ron_60]

On j'ai trouvé exactement le problème, on ne peut pas modifier chemin un dossier notifié par FindFirstChangeNotification. Dans mon exemple si on notifie photos, on ne peut modifier "mon dossier". Par contre on peut le supprimer.

Du fait de cela on ne peut pas faire plus de 2 notifications avec un chemin incluant l'autre sans avoir de problème.

Je vais devoir utiliser un notification général (avec l'option subtree) et verifier tous les dossiers pour savoir le quel a été modifié. A moins qu'il y a un quelqu'un qui a une autre solution.

il y a la même chose dans ReadDirectoryChangesW . Autant tous consente au même endroit.