Discussion :

[killer69]

salut tt le monde

ma question est simple

comment vérifier si un fichier est ouvert avant de le supprimer. parce que si non il y aura un message d'erreur

[smyley]

Ben tu peut le supprimer et entourer la suppression d'un try-catch pour attrapper l'erreur. Je ne crois pas qu'il y ai de moyens faciles de trouver si un fichier est actuellement ouvert. Si un tel moyen existe, j'aurai bien aimé le connaitre ...

[StormimOn]

C'est aussi simple d'essayer de le supprimer (try/catch) et de mettre un message si la suppression n'a pas réussie non ?

Parce que si tu vois que le fichier est ouvert, que vas-tu faire si ce n'est mettre un message ?

Edit : grilled par smyley.

Sinon smyley, je pense que si tu tentes de créer un FileStream, sur le fichier dont tu veux tester l'ouverture, avec FileShare.None en option ca devrait te lever une exception si le fichier est déjà ouvert, enfin il me semble car je n'ai pas de quoi tester sous la main ^^

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
try
{
    FileStream stream = new FileStream(filePathName, FileMode.Open, FileAccess.Read, FileShare.None);
}
catch(Exception ex)
{
    ...
}

[killer69]

je vasi tester vos 2 propositions.

mais à vrai dire j'ai fouiller sur tous les forums et y a beaucoup de gens qui veulent savoir si existe-elle une tell eméthode

[smyley]

Non à vrai dire avec l'exception tu sais qu'il y a eu une erreur lors de l'accès au fichier. Il est peut être ouvert, peut être qu'il n'existe pas, peut être que l'accès a été refusé, peut être que le disque de destination n'est plus accessible, etc etc...
Ce que j'ai recherche c'est plus un moyen d'avoir la certitude que le fichier est véritablement ouvert par une autre application, et savoir quelle application ...

[StormimOn]

C'est sûr que suivant les cas possibles, le contexte qui gravite autour, ... pas mal de choses peuvent influer et ouvrir en FileShare.None peut ne pas suffir. Dans un cadre moins "strict", cela peut suffir. Par contre ca ne dit pas quel processus a le fichier.

Je crois qu'il existe un utilitaire en ligne de commande ("Open handle" ou un truc du genre, c'est avec un truc pour Windows XP de mémoire) qui renvoie les process utilisant un fichier donné en paramètre de l'utilitaire, avec une redirection c'est vite fait d'avoir ca dans un fichier texte. Maintenant le fichier est-il facilement traitable c'est autre chose.

Parce que sinon pour faire ca en C# je ne suis pas sûr que cela soit possible. Je ne suis pas spécialiste des WMI, mais il y a peut être des choses intéressantes de ce côté ? Enfin si l'utilisation des WMI est possible dans le cadre en question ^^

[killer69]

waw ça comence à chauffer entre les géants de l'informatique,

y a des choses intéressante dans ces 2 dernières réponses.

je penche dessus tt de suite

[smyley]

Je crois qu'il existe un utilitaire en ligne de commande ("Open handle" ou un truc du genre, c'est avec un truc pour Windows XP de mémoire) qui renvoie les process utilisant un fichier donné en paramètre de l'utilitaire, avec une redirection c'est vite fait d'avoir ca dans un fichier texte. Maintenant le fichier est-il facilement traitable c'est autre chose.

http://www.developpez.net/forums/sho...d.php?t=423998
Le truc c'est que l'histoire de dépendre d'une autre application ne me plaisait pas, justement, j'aurai préféré une petite dll native mais apparament ça n'existe pas ( du moin, pas que je sache ... ). On sais jamais si l'exe va démarrer et tout ( d'ailleurs, j'ai un problème sur mon projet actuel ou mon programme de suppression semble ne pas démarrer ... ).
L'autre solution sera d'aller utiliser l'api native de Windows mais ça doit être du des choses qui change le plus d'une version à l'autre et donc tout ce que j'avais trouvé dessus indiquait que ces fonctions pourraient être supprimées dans les prochaines versions de Windows ...

Je ne suis pas spécialiste des WMI, mais il y a peut être des choses intéressantes de ce côté ? Enfin si l'utilisation des WMI est possible dans le cadre en question ^^

ça semble plus faisable ça mais moi non plus je m'y connais pas en WMI ( y a t il un connaisseur ici ? )

waw ça comence à chauffer entre les géants de l'informatique

Ceci dit pour en revenir à ton problème je pense que tu n'aura pas besoin de tant de complication ...

[Bluedeep]

Non à vrai dire avec l'exception tu sais qu'il y a eu une erreur lors de l'accès au fichier. Il est peut être ouvert, peut être qu'il n'existe pas, peut être que l'accès a été refusé, peut être que le disque de destination n'est plus accessible, etc etc...

Pas du tout !

Si on utilise le File.Delete (ns System.IO)

- il n'y a pas d'exception si le fichier n'existe pas
- les exceptions en cas de fichier en utilisation ou de problème d'autorisation, de directory inexistant, etc .. sont différentes.

Ce que j'ai recherche c'est plus un moyen d'avoir la certitude que le fichier est véritablement ouvert par une autre application, et savoir quelle application ...

Tu l'as : IOException.

Il suffit de ne pas filtrer les autres cas. cf MSDN

[ced600]

Sinon je crois que c'est possible de détecter l'utilisation d'un fichier par une autre application sans passer par les exceptions.
EN fait je n'en suis pas réellement sur, mais je viens de penser à quelque chose.

Dernièrement en VBS j'ouvre un fichier excel pour faire des trucs. Ce même fichier est déjà ouvert par moi même pour voir ce qu'il contient.
Bref tout ceci pour dire que si vous ouvrez un fichier excel et qu'autre chose ou quelqu'un d'autre l'ouvre sur le même poste, alors il ne l'ouvrira qu'en lecture seul. On peut observer ce comportement en fermant le fichier read/write, et alors excel vous propose de passer l'autre instance d'excel en R/W sur le fichier et non Read only.

Bref ce que propose excel est certainement lié à excel lui même. Mais le fait que la deuxième instance d'excel ne puisse ouvrir le fichier qu'en lecture seul, je en suis pas sur que cela soit un comportement d'excel, je pencherais pour un comportement de windows.

Donc l'idée dans notre cas serait d'ouvrir le fichier, et de vérifier si les droits pour cette instance sont ReadOnly ou Read/Write.

En WMI, hum avec cette methode de l'objet CIM_DataFile peut être.

Mais la propriété InUseCount de CIM_LogicalFile semble mieux convenir :

InUseCount
Data type: uint64
Access type: Read-only

Number of "file opens" that are currently active against the file.

[clodo13]

Sinon je crois que c'est possible de détecter l'utilisation d'un fichier par une autre application sans passer par les exceptions.
EN fait je n'en suis pas réellement sur, mais je viens de penser à quelque chose.

Dernièrement en VBS j'ouvre un fichier excel pour faire des trucs. Ce même fichier est déjà ouvert par moi même pour voir ce qu'il contient.
Bref tout ceci pour dire que si vous ouvrez un fichier excel et qu'autre chose ou quelqu'un d'autre l'ouvre sur le même poste, alors il ne l'ouvrira qu'en lecture seul. On peut observer ce comportement en fermant le fichier read/write, et alors excel vous propose de passer l'autre instance d'excel en R/W sur le fichier et non Read only.

Bref ce que propose excel est certainement lié à excel lui même. Mais le fait que la deuxième instance d'excel ne puisse ouvrir le fichier qu'en lecture seul, je en suis pas sur que cela soit un comportement d'excel, je pencherais pour un comportement de windows.

Donc l'idée dans notre cas serait d'ouvrir le fichier, et de vérifier si les droits pour cette instance sont ReadOnly ou Read/Write.

En WMI, hum avec cette methode de l'objet CIM_DataFile peut être.

Mais la propriété InUseCount de CIM_LogicalFile semble mieux convenir :

Je te confirme ce soir mais j'ai déja pensé a sa ! et je crois que sa fonctionne pas :!

[smyley]

Pas du tout !

Si on utilise le File.Delete (ns System.IO)

ouai ... sauf qu'on parlais du FileStream là ...