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

[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.

[smyley]

Pas du tout !

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

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