[VBNET]Comment être sûr que fichier est écrit avant lecture?

Version imprimable

19/03/2006, 19h10
Garrett

[VBNET]Comment être sûr que fichier est écrit avant lecture?

Comment puis-je coder mon application vb.net afin qu'elle attende à un certain point de son exécution, que tous les fichiers textes qu'elle écrit, soient complètement écrits sur le disque avant de continuer. Ces fichiers textes servent d'espaces d'échange de données entre mon application et une autre dont je n'ai pas accès au code source.

Le problème est que l'écriture de fichiers sur le disque est quelque chose d'asynchrone, j'avais penser aux fonctions synchronize et lock des streamwriters, mais sans succès (ou alors je les ai mal utilisées).

Si vous avez déjà été confronté à ce problème ou que vous avez la moindre idée, je vous en serai très reconnaissant. Merci d'avance.
20/03/2006, 07h36
neguib

La gestion des exceptions peut être une piste, en modifiant le paramètre FileShared du flux sur le fichier. Ainsi ce flux en lecture ne sera possible que si l'accès du flux en ecriture est bien libéré.
20/03/2006, 08h36
Garrett

Merci, je vais d'abord essayer ça avec try...catch avant que mon application vb.net ne redonne la main à la seconde application.

Je posterai un exemple si cela fonctionne.

J'ai utilisé ceci :
Code:

1 2 3 4 5 6 7 Dim newfile As New System.IO.FileStream(AdjustedFile, FileMode.Create, FileAccess.Write, FileShare.None, 0, False) Dim outline As New StreamWriter(newfile) ... le reste du prog ... outline.Flush() outline.Close()
A prioris, ça fonctionne mais puis-je affirmer à 100% à 100% que l'écriture est à synchrone et que toute information est bien écrite sur le disque avant mon programme vb.net redonne la main à mon second programme ?

26/03/2006, 19h05
neguib

Difficile de te répondre car je ne vois pas où se trouve la gestion d'exception :koi:
26/03/2006, 21h12
Maniak

Citation:

Envoyé par Garrett

A prioris, ça fonctionne mais puis-je affirmer à 100% que l'écriture est à synchrone et que toute information est bien écrite sur le disque avant mon programme vb.net redonne la main à mon second programme ?

D'après la doc, l'écriture de tout le buffer est faite à ton appel à Flush (ou Close s'il n'y avait pas Flush avant, qui devrait donc être facultatif dans ce cas).
Donc, toujours d'après la doc, oui, après Flush/Close le fichier est écrit.
27/03/2006, 07h58
Garrett

Merci, je vais voir ça.

y'a ca aussi

j'ai trouvé ca dans les FAQ, l'auteur est ABELMAN, cela monitor l'etat d'un repertoire ou d'un fichier selon l'action qui lui est executée... et selon cette meme action tu declenches ou non ton code.

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
 
Imports System.IO 
 
Sub Watch(ByVal sPath As String, Optional ByVal sFilter As String = "*") 
'On peut utiliser les '*' avec sFilter  Dim fw As New FileSystemWatcher(sPath, sFilter) 
'On ajoute les handler pour surveiller les évènements qu'on souhaite.  
AddHandler fw.Changed, AddressOf OnChanged
AddHandler fw.Renamed, AddressOf OnRenamed
AddHandler fw.Created, AddressOf OnChanged
AddHandler fw.Deleted, AddressOf OnChanged
AddHandler fw.Error, AddressOf OnError
'On surveillera aussi les sous répertoires  
fw.IncludeSubdirectories = True  
' Mettre cette propriété à True démarre la surveillance des modifications. La mettre à false l'arrête.  
Dans notre exemple, elle sera à true durant tout le programme fw.EnableRaisingEvents = True  
End Sub  
 
Sub OnChanged(ByVal source As Object, ByVal e As FileSystemEventArgs) 
Console.WriteLine("File {0} {1}", e.FullPath, e.ChangeType) 
End Sub  
 
Sub OnRenamed(ByVal source As Object, ByVal e As RenamedEventArgs)
 Console.WriteLine("File {0} renamed to {1}", e.OldFullPath, e.FullPath) 
End Sub
 
Sub OnError(ByVal source As Object, ByVal e As ErrorEventArgs) Dim ex As Exception = e.GetException()  
Debug.WriteLine(ex.ToString()) Console.WriteLine(ex.Message) 
End Sub

28/03/2006, 08h04
Garrett

Merci mais j'avais déjà essayé les FileSystemWatcher avec une adaptation de l'exemple de l'aide msdn. En fait, cela contrôle tout ce que l'utilisateur fait mais pas ce qu'un logiciel exécute. Si un programme crée, modifie ou supprime un fichier, ça ne se voit pas, ou pas comme un événement recevable par un FileSystemWatcher.
Sinon l'idée était bonne.

J'utilise la propriété autoflush des streamwriters combinée avec une écriture synchrone et pour l'instant ça marche. Je vais faire encore quelques tests avant de confirmer.