Créer un fichier avec DeleteAfterOpen et permettre à un autre processus de lire le fichier

Question

Est-il possible de créer un fichier en utilisant l'objet FileStream dans .net, en spécifiant l'option DeleteAfterClose et d'autoriser l'accès en lecture à ce fichier?

J'ai essayé d'utiliser:

System.IO.FileStream strBMP = new System.IO.FileStream(sFileName, System.IO.FileMode.Create, System.Security.AccessControl.FileSystemRights., System.IO.FileShare.ReadWrite, 1024, System.IO.FileOptions.DeleteOnClose); 

mais l'autre objet de tenter la lecture devient une violation de partage de fichiers.

J'essaye de faire ceci parce que je crée le fichier (a tif), et ensuite en utilisant un objet COM (MODI) pour effectuer l'OCR sur l'image. Mon problème est que veille après avoir appelé la méthode close sur l'objet com MODI, je n'arrive toujours pas à supprimer le fichier en utilisant la méthode System.File.Delete car l'objet COM MODI n'est pas tout à fait fini avec lui. Je pensais que si je pouvais créer mon fichier avec l'option DeleteAfterClose, et permettre toujours la lecture sur ce fichier que je serais défini, je ne peux pas comprendre comment passer la violation de partage - si c'est même possible.

Answer 1

Lorsque deux processus ouvrent le même fichier, les deux doivent spécifier des ensembles compatibles d'indicateurs de partage de fichiers pour que le second ouvert réussisse. À moins que vous ne puissiez contrôler les drapeaux transmis par MODI lors de l'ouverture du fichier, il n'y a probablement aucun moyen d'éviter la violation de partage; par exemple, s'il tente d'ouvrir le fichier en mode exclusif, il échouera toujours si le fichier est ouvert dans votre processus, quels que soient les indicateurs transmis au constructeur FileStream.

Un objet COM bien conçu (ce qui peut ou peut ne pas être le cas ici) ne laisserait pas les fichiers ouverts lors de sa sortie, donc le problème peut être lié à la couche d'interopérabilité .NET COM; il est possible que certains objets MODI COM restent en vie de manière imprévue. En effet, threads sur d'autres forums sur this problem tous mentionnent le code managé. Il est possible qu'une combinaison de Marshal.FinalReleaseComObject, GC.Collect et GC.WaitForPendingFinalizers puisse aider à résoudre le problème, mais personne ne semble avoir encore écrit une solution définitive (encore) et l'utilisation de ces fonctions semble extrêmement hacky et très fragile.