2010-02-25 19 views
3

J'ai de nombreux processus de lecture d'un fichier stocké sur un partage réseau. A l'origine, je n'avais qu'un seul processus pour lire le fichier, tous les autres lançaient des exceptions. Je mis en œuvre le code suivant pour traiter que:Méthodes appropriées pour que plusieurs processus lisent le même fichier?

using (StreamReader fileStreamReader = new StreamReader(File.Open(path, FileMode.Open, FileAccess.Read, FileShare.Read))) 
{ 
    content = fileStreamReader.ReadToEnd(); 
} 

Cela laisse plusieurs processus lisent le même fichier, mais il semble encore avoir des problèmes, parce que parfois plusieurs processus ne peuvent toujours pas accéder au fichier. Pourtant, je peux revenir plus tard lorsque le fichier n'est pas utilisé et l'ouvrir très bien. À l'heure actuelle, j'ai un certain nombre de tentatives avec des retards aléatoires mis en œuvre que jusqu'à présent, semblent aider. Cela me semble un peu bizarre de le faire de cette façon, alors quelle serait la meilleure méthode?

Ceci est la partie étrange, l'exception que je reçois n'est pas du tout du fichier IO du tout, il s'agit d'une bibliothèque appelée CommStudio. En bref, je jette le fichier à une chaîne, je le modifie légèrement, le vider dans un flux de mémoire, et l'expédier sur ymodem sur rs232. L'exception me dit que le système distant a été annulé. Le périphérique obtenant les données signale une erreur de transmission, ce qui signifie généralement qu'un fichier incomplet/vide a été reçu.

Normalement, je blâmerais la bibliothèque à ce sujet, mais cela fonctionne parfaitement lors des tests de bureau et lorsqu'il n'y a qu'un seul processus qui accède au fichier. La seule chose qui semble vraiment cohérente est qu'elle risque d'échouer lorsque plusieurs processus accèdent à un fichier.

+0

Le verrouillage sur des partages réseau peut être un pita. pouvez-vous indiquer les partages réseau que vous utilisez (Windows version, unix?) et quelles exceptions obtenez-vous? – stmax

+0

Les clients utilisent XP, le serveur est Windows Server, je pense 2008, mais pas tout à fait sûr. Je poste une modification à propos de l'exception. – MGSoto

+1

lisez-vous toujours les mêmes fichiers? vous pourriez essayer de calculer une somme de contrôle (voir la classe SHA1 par exemple) après avoir lu les fichiers pour vérifier s'ils ont été lus correctement. Si les sommes de contrôle sont correctes, vous savez que l'erreur provient du périphérique et non de la lecture depuis le partage réseau. – stmax

Répondre

2

avait un problème similaire mais pas beaucoup de temps pour trouver une solution idéale. J'ai créé un webservice et collé le fichier local à l'application webservice .. puis créé un simple GET API qui a été appelé sur l'intranet du bureau .. assurant ainsi que l'application appelante a édité le fichier journal .. désordonné mais fonctionnel.

+0

Solution intéressante. Je l'aime bien, mais je ne pense pas que j'aurai trop de votes pour cette solution. Cependant cela me donne une idée puisque j'ai un programme maître qui contrôle tous les processus, et qui pourrait éventuellement alimenter les processus les fichiers dont ils ont besoin ... Mais finalement il y aura plusieurs de ceux qui fonctionnent aussi, et je préférerais aller chercher une solution garantie. – MGSoto

0

J'ai eu un problème similaire dans le passé. Essayez de changer la façon dont vous accédez au fichier à quelque chose comme ça.

//Use FileInfo to get around OS locking of the file 
FileInfo fileInfo = new FileInfo(path); 
//I actually wanted unblocked read write access so change your access and share appropriately 
using (FileStream fs = fileInfo.Open(FileMode.Open, FileAccess.Write, FileShare.ReadWrite)) 
{ 
    //I'm using CopyTo but use whatever method matches your need 
    fileInfo.CopyTo(Path.Combine(destination, fileName), false); 
}