Discussion :

[white_tentacle]

Bonjour,

J'ai une appli (dont je n'ai évidemment pas le code source et que je ne peux pas modifier) qui écrit un fichier dans un répertoire, puis l'efface pour en réécrire un autre dans ce même répertoire, et ainsi de suite...

J'aimerai récupérer chacun de ces fichiers pour les avoir tous dans un répertoire "à part" (pour pouvoir les traiter). Je suis sous windows (NT ou 2K).

Pour ce faire, j'ai envisagé plusieurs solutions :

• monitorer les écritures, faire un move du fichier dès le close. Ça ne me semble pas satisfaisant, car je suspecte fortement que l'appli puisse tenter d'écrire le fichier lorsque je suis en train de faire le move, que ça échoue lamentablement et qu'elle ne s'en remette pas
• Créer un driver windows qui se charge de la duplication (pas trop sûr que je puisse mettre un répertoire en tant qu'input de mon driver)
• Hooker les appels à CreateFile, etc... pour les passer par du code à moi qui ferait l'écriture à deux endroits.

D'où, questions :

• Quelle approche vous semble la plus raisonnable ?
• Avez-vous une idée d'une autre approche ?

Merci

[Mac LAK]

Peut-être tout simplement faire un groupe d'utilisateurs spécial, enlever les droits de suppression pour ce groupe sur le répertoire de sortie, et exécuter ton programme avec les privilèges de ce groupe ?

[white_tentacle]

Ce serait peut-être envisageable, mais ça a toutes les chances de casser le fonctionnement de l'autre appli (je n'ai aucune confiance en sa robustesse).

Par contre, je pense finalement m'orienter vers les filter drivers, ça semble la solution la plus adaptée.

[Mac LAK]

DeleteFile, sûrement la fonction utilisée derrière, est plutôt du genre à devoir être testée explicitement pour savoir si ça s'est bien passé... Si ton application tierce est aussi peu propre que tu le supposes, il y a peu de chances qu'ils testent le résultat.

Tu fais comme tu le sens, mais moi, en tout cas, j'essaierai d'abord avec des droits restreints et une notification sur les changements du répertoire de sortie. Si ça ne marche pas, alors envisager autre chose...

[white_tentacle]

Je ne suis même pas sûr que DeleteFile soit utilisé, je soupçonne plutôt un CreateFile qui écrase le fichier précédent.

Comme je ne suis pas sur site pour l'instant, je ne peux rien vérifier/tester, donc il me faut une solution dont je sois sûr qu'elle marche...

[Mac LAK]

Je ne suis même pas sûr que DeleteFile soit utilisé, je soupçonne plutôt un CreateFile qui écrase le fichier précédent.

D'après ton message d'origine ("qui écrit un fichier dans un répertoire, puis l'efface pour en réécrire un autre dans ce même répertoire, et ainsi de suite..."), je pensais que chaque fichier avait un nom différent d'une itération à l'autre...

S'il écrase systématiquement le même nom de fichier, c'est plus tout à fait la même histoire...

Comme je ne suis pas sur site pour l'instant, je ne peux rien vérifier/tester, donc il me faut une solution dont je sois sûr qu'elle marche...

C'est là aussi où il y a un problème : à part créer un lecteur virtuel complet que tu maîtrise de A à Z, tu n'auras aucune solution réellement fiable sans faire des essais.

[white_tentacle]

C'est là aussi où il y a un problème : à part créer un lecteur virtuel complet que tu maîtrise de A à Z, tu n'auras aucune solution réellement fiable sans faire des essais.

Disons qu'il y a des solutions où je suis clairement dépendant du comportement du programme, et d'autres non/moins. Du coup, je préfère m'orienter vers la deuxième catégorie .

Si tu as déjà bossé avec les filter driver ou les hook systèmes, je veux bien un avis, sinon, reste plus qu'à croiser les doigts .

[Mac LAK]

Si tu as déjà bossé avec les filter driver ou les hook systèmes, je veux bien un avis, sinon, reste plus qu'à croiser les doigts .

J'en ai déjà utilisé, mais jamais créés moi-même... Donc, pas d'autre solution à te proposer.

[maxim_um]

Salut,

J'ai une appli (dont je n'ai évidemment pas le code source et que je ne peux pas modifier) qui écrit un fichier dans un répertoire, puis l'efface pour en réécrire un autre dans ce même répertoire, et ainsi de suite...

Cette "information" n'est vraiment pas exploitable.
Sans plus de détails, cela reviendrait à discuter dans le vide.