Problème avec ReadDirectoryChangesW

Version imprimable

05/10/2011, 17h54
Nico118

Problème avec ReadDirectoryChangesW

bonjour,

J'ai un problème avec ReadDirectoryChangesW. Je cherche à surveiller un répertoire et faire une action lorsque des fichiers sont ajoutés dans ce répertoire (par un autre processus que je ne contrôle pas).

Avec ReadDirectoryChangesW je détecte bien la création d'un fichier mais je souhaite en plus détecter la fin de création de ce fichier. Ces fichiers que je souhaite manipuler font parfois plusieurs Go or ça prend du temps pour se copier ce qui me cause quelques soucis :cry:

Avec ReadDirectoryChangesW existe t il un moyen de ne déclencher l'événement FILE_ACTION_ADDED que lorsque le fichier est fini de copier?

Merci d'avance pour votre aide.
07/10/2011, 15h37
Emmanuel Deloget

Citation:

Envoyé par Nico118

Avec ReadDirectoryChangesW existe t il un moyen de ne déclencher l'événement FILE_ACTION_ADDED que lorsque le fichier est fini de copier?

Pas que je sache. Ceci dit, comment-est ce que tu défini "fini de copier" ?
07/10/2011, 16h06
therwald

Je réfléchis de façon abstraite car je ne connais pas la(les) API(s) concernées, mais Nico118 ne pourrait-il pas utiliser son évènement pour ajouter le fichier à une liste de fichiers en cours d'écriture, et surveiller régulièrement pour voir quand le fichier est fermé en écriture? A moins que le process qui ajoute les fichiers ne fasse la copie en ouvrant le fichier en mode ajout plusieurs fois de suite, ne peut-il pas détecter le fait que le fichier est ouvert en écriture, et définir la fin de copie comme le moment où le fichier est refermé par le process qui fait la copie?
07/10/2011, 16h34
Nico118

Citation:

Envoyé par Emmanuel Deloget

Pas que je sache. Ceci dit, comment-est ce que tu défini "fini de copier" ?

Quand je dit fini de copier pour moi ça veut dire que tous les octets du fichiers sont copiés :oops:
07/10/2011, 16h59
Emmanuel Deloget

Citation:

Envoyé par Nico118

Quand je dit fini de copier pour moi ça veut dire que tous les octets du fichiers sont copiés :oops:

Oui, mais pour l'ordinateur, ça n'a aucun sens. Pour lui, il s'agit d'un ensemble d'écriture dans le fichier. Il peut détecter la création du fichier, ou une modification de sa taille, mais il ne pourras jamais te dire "ca y est, il a fini de grossir". Ne sachant pas que le fichier est généré lors d'une copie, il n'a aucune information sur laquelle il pourrait se baser.
07/10/2011, 17h05
therwald

Citation:

Envoyé par Emmanuel Deloget

Il peut détecter la création du fichier, ou une modification de sa taille, mais il ne pourras jamais te dire "ca y est, il a fini de grossir".

Donc, sais-tu si des API existent permettant de détecter que le fichier est actuellement ouvert en écriture par un process quelconque? Si le process qui copie le fichier fait son écriture en une fois (ouvre en écriture, balance toutes les données, j'ai finit, ferme le fichier), on pourrait déduire que la copie est finie du fait que le fichier est fermé en écriture. Est-ce que ça tient assez la route pour résoudre le problème de Nico118?
07/10/2011, 17h16
Nico118

Citation:

Envoyé par therwald

Donc, sais-tu si des API existent permettant de détecter que le fichier est actuellement ouvert en écriture par un process quelconque? Si le process qui copie le fichier fait son écriture en une fois (ouvre en écriture, balance toutes les données, j'ai finit, ferme le fichier), on pourrait déduire que la copie est finie du fait que le fichier est fermé en écriture. Est-ce que ça tient assez la route pour résoudre le problème de Nico118?

J'ai pensé à ça mais je n'ai pas réussi à le faire :cry:
07/10/2011, 17h18
therwald
Pourrais-tu détailler les raisons de ton échec?
est-ce que:
- tu n'as pas trouvé d'API pour faire ça
- ça se déclenche en cours de copie (ton process copieur ferme et réouvre le fichier plusieurs fois au cours de la copie)
- autre chose?
07/10/2011, 19h38
Nico118

Le process copieur (que je ne maitrise pas) copie le fichier d'un seul coup (c'est à dire que pour ce process le fichier est déjà complet lorsqu'il commence sa copie, il n'a pas de modification à faire sur ce fichier). La copie du fichier par l'autre process met un certain temps (le fichier peut faire plusieurs Go et la copie se fait au travers un réseau local), j'utilise ReadDirectoryChangesW pour surveiller le répertoire où sont copiés ces fichiers et mon problème c'est que ça me détecter qu'un fichier arrive, pas qu'un fichier est arrivé.
07/10/2011, 21h40
therwald
Citation:

Envoyé par Nico118

Le process copieur (que je ne maitrise pas) copie le fichier d'un seul coup (c'est à dire que pour ce process le fichier est déjà complet lorsqu'il commence sa copie, il n'a pas de modification à faire sur ce fichier). La copie du fichier par l'autre process met un certain temps (le fichier peut faire plusieurs Go et la copie se fait au travers un réseau local), j'utilise ReadDirectoryChangesW pour surveiller le répertoire où sont copiés ces fichiers et mon problème c'est que ça me détecter qu'un fichier arrive, pas qu'un fichier est arrivé.

Soyons bien clairs: combien de processus y-a-t'il?
Je croyais qu'il y en avait deux:
- un processus copieur (disons p1) (crée les fichiers, met un certain temps car il ramène plusieurs Go)
- ton processus (disons p2) (surveille pour faire une opération X sur les nouveaux fichiers)
Est-ce que c'est bien ça?

Si oui, la question est: comment fait p1? Est-ce qu'il ouvre le ficher en écriture et la garde ouvert tout le temps jusqu'à fin du transfert? Ou est-ce qu'il écrit les données par paquets d'un certaine taille en REFERMANT le fichier entre ses écritures?
Si c'est le premier cas (une seule grande écriture, le fichier reste ouvert en écriture tant que la copie du fichier n'est pas finie) alors on pourrait une fois qu'on a listé le fichier comme ajouté par l'évènement sonder à intervalles réguliers jusqu'à ce qu'il soit fermé. Là on peut le traiter, car on sait que la copie est terminée. Si c'est le second cas (le processus p1 ferme puis ré-ouvre le fichier plusieurs fois au cours du processus de copie au fur et à mesure qu'il reçoit les données à travers le réseau) alors on ne peut pas s'en tirer par la détection de la fermeture du fichier, puisqu'il est plusieurs fois fermé et ré-ouvert avant la vraie fin de la copie.

Sinon, lorsque tu dis que tu n'a pas de contrôle sur p1, veux tu dire que c'est un processus séparé ou que tu ne peux rien faire modifier dessus? Parce que si tu pouvais le faire modifier, tu pourrais faire en sorte qu'il fasse le transfert sur un autre répertoire DE LA MÊME PARTITION, puis qu'il déplace le fichier entier vers le répertoire que tu surveille. Comme ça vu que les données sont déjà là et qu'on ne fait que mettre à jour un lien, le fichier apparaîtrait dans le répertoire surveillé "d'un seul coup" (en fait en un temps très bref). Et ça devrait résoudre ton problème.
08/10/2011, 05h15
Mat.M

Citation:

Envoyé par Nico118

mais je souhaite en plus détecter la fin de création de ce fichier. .

Est-ce que tu utilises des EVENT ?
Il faut créer un EVENT et appeler WaitForSingleObject.
D'après les explications données ce ne semble pas le cas

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Tu as tout un exemple détaillé ici
http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx

Mon code ressemble à ça :

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
30
31
32
33
34
while(1) {
	hDir = CreateFile(
		Rep_FromAutomate,
		FILE_LIST_DIRECTORY,
		FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
		NULL,
		OPEN_EXISTING,
		FILE_FLAG_BACKUP_SEMANTICS,
		NULL);
 	bResult = ReadDirectoryChangesW(
		hDir,
		Buf,
		10000,
		FALSE,
		FILE_NOTIFY_CHANGE_FILE_NAME | FILE_NOTIFY_CHANGE_SIZE | FILE_NOTIFY_CHANGE_LAST_ACCESS,
		&RetBytes,
		NULL,
		NULL);
 
	for(;;) {
 
	pInfo = (FILE_NOTIFY_INFORMATION *)&Buf[dwi];
switch(pInfo->Action) {
	case FILE_ACTION_ADDED:
break;
case FILE_ACTION_REMOVED:
	printf("fichier supprime : %s\n", sNomFichier);break;
default: 
	printf("autre action sur le répertoire\n");
	break;
}
};
 
CloseHandle(hDir);

10/10/2011, 10h18
Emmanuel Deloget

Citation:

Envoyé par therwald

Donc, sais-tu si des API existent permettant de détecter que le fichier est actuellement ouvert en écriture par un process quelconque? Si le process qui copie le fichier fait son écriture en une fois (ouvre en écriture, balance toutes les données, j'ai finit, ferme le fichier), on pourrait déduire que la copie est finie du fait que le fichier est fermé en écriture. Est-ce que ça tient assez la route pour résoudre le problème de Nico118?

Oui, mais qui te dis que le fichier sera ouvert et copié en une fois ? A moins d'avoir une contrôle quasi total le logiciel qui fait la copie, tu ne peux pas en être sûr. D'autant plus qu'un utilisateur peut avoir installé un hook sur CopyFile et CopyFileEx (par exemple pour utiliser Teracopy).

Donc, en théorie, ça peut aider si c'est effectivement ce qui se passe, mais en pratique, un tel comportement ne peut pas être garanti.

Pour déterminer si un fichier est ouvert en écriture par quelqu'un d'autre, il suffit de vérifier s'il est ouvrable de manière exclusive. S'il ne l'est pas, mais qu'il existe, alors le fichier est en cours d'utilisation. Donc : OpenFile() avec OF_SHARE_EXCLUSIVE comme flag.

Citation:

OF_SHARE_EXCLUSIVE (0x00000010)
Opens a file with exclusive mode, and denies both read/write access to other processes. If a file has been opened in any other mode for read/write access, even by the current process, the function fails.

cf. http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx
10/10/2011, 10h44
Nico118
Merci pour toutes vos réponses.

Donc il faudrait que je code quelque chose du genre ?
Code:

1 2 3 while(OpenFile(lpFileName, lpReOpenBuff, OF_SHARE_EXCLUSIVE)) { }
Si mon fichier met plusieurs minutes pour être fini de copier, je suis aveugle pendant ce temps non?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
do {
  // pas DENY_WRITE, mais bien EXCLUSIVE. Les deux valeurs n'ont pas du tout la 
  // même sémantique, et c'est la sémantique de EXCLUSIVE que tu cherches
  // a obtenir.  
  HFILE f = OpenFile(lpFileName, lpReOpenBuff, OF_SHARE_EXCLUSIVE);
  if (f != HFILE_ERROR) {
    // si on a réussi à ouvrir le fichier, on est bon. 
    CloseHandle(f);
    break;
  }
  Sleep(0); // au moins ; Un sleep plus important ne serait pas plus mal ; voir ce que tu peut mettre ici (50 ? 100 ? 250 me semble être pas mal). 
}
//SetEvent(hEventFileOk);

Dans l'idéal, ce code est placé dans un thread, et ce thread fait un SetEvent() une fois que le fichier est considéré comme OK.

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
struct filecheckinfo
{
  std::string filename;
};
 
DWORD WINAPI my_thread_func(LPVOID param)
{
  filecheckinfo* fci = reinterpret_cast<filecheckinfo*>(param);
  if (!fci)
    return (DWORD)(-1);
  do {
    // pas DENY_WRITE, mais bien EXCLUSIVE. Les deux valeurs n'ont pas du tout la 
    // même sémantique, et c'est la sémantique de EXCLUSIVE que tu cherches
    // a obtenir.  
    OFSTRUCT reopenbuf;
    HFILE f = OpenFileA(fci->filename.c_str(), &reopenbuf, OF_SHARE_EXCLUSIVE);
    if (f != HFILE_ERROR) {
      // si on a réussi à ouvrir le fichier, on est bon. 
      CloseHandle(f);
      break;
    }
    Sleep(250);
  }
  return 0;
}
 
// A appeler dans le thread d'attente du fichier. 
// a noter que le WaitForSingleObject peut prendre une paramètre de timeout qui n'est pas
// INFINITE, ce qui va le faire échouer régulièrement sur une erreur WAIT_TIMEOUT. 
// Du coup, un autre traitement est possible toutes les X millisecondes si besoin. 
DWORD do_check(const std::string filename)
{
  filecheckinfo fci; 
  DWORD result;
 
  HANDLE hthread = CreateThread(NULL, 0, my_thread_func, (LPVOID)(&fci), 0, NULL);
  if (hthread == INVALID_HANDLE_VALUE)
    return (DWORD)(-1);
 
  WaitForSingleObject(hthread, INFINITE);
 
  GetExitCodeThread(hthread, &result);
  return result;
}

Ceci dit, effectivement, tant que le fichier n'est pas accessible, tu ne peux pas faire grand chose. C'est à toi de trouver la parade.

A noter aussi que tu peux avoir plusieurs threads en parallèle qui vérifie si un fichier parmi plusieurs est dispo (grâce à WaitForMultipleObjects).

Enfin bon, après, c'est toi qui voit :)

Ce code me lève une exception :
Code:

1 2 3 4 5 6 7 8 9 10 11 do { res = OpenFile(new_fichier.c_str(), reopenbuf, OF_SHARE_EXCLUSIVE); if (res != HFILE_ERROR) { // si on a réussi à ouvrir le fichier, on est bon. CloseHandle((HANDLE)res); break; } Sleep(50); } while(1);
Citation:

Une exception non gérée du type 'System.AccessViolationException' s'est produite dans Test.exe

Informations supplémentaires*: Tentative de lecture ou d'écriture de mémoire protégée. Cela indique souvent qu'une autre mémoire est endommagée.

Note qu'en remplaçant OF_SHARE_EXCLUSIVE par OF_READ je n'ai pas d'exception mais res (le HFILE) vaut toujours -1 donc je reste bloqué dans ma boucle même après la fin de la copie du fichier.

Pour mes tests, le second process (celui qui copie les gros fichiers dans mon répertoire) est simulé par un copier coller depuis l'explorateur Windows 7.