Incertitude quant au mécanisme de verrouillage des fichiers en C#.NET

Question

Dans mon environnement de test, j'ai deux clients physiques Windows 7. Tous deux ont accès à un partage réseau, hébergé sur un système Windows Server.

Les clients, respectivement, exécutent une application qui peut tenter d'opérer (lire ou écrire) sur le même fichier texte au même moment.

Je veux utiliser le FileInfo.Open() pour réaliser différents scénarios :

Scénario 1 : L'application permet de lire en même temps. Elle doit échouer si une autre instance est en train d'y écrire.

J'utiliserais

FileInfo fi = new FileInfo(filePath);
using (FileStream fs = fi.Open(FileMode.Open, FileAccess.Read, FileShare.Read))
{
    // Do some read operations...
    Console.WriteLine("Press ENTER to close file-stream...");
    Console.ReadLine();
}

pour ça.

Scénario 2 : Une seule instance est autorisée à ouvrir un fichier pour tenter d'y écrire. Et elle doit échouer si une autre instance est en train de le lire.

J'utiliserais

FileInfo fi = new FileInfo(filePath);
using (FileStream fs = fi.Open(FileMode.Open, FileAccess.Write, FileShare.None))
{
    // Do some write operations...
    Console.WriteLine("Press ENTER to close file-stream...");
    Console.ReadLine();
}

pour ça.

---

Avec les extraits de code ci-dessus, mes scénarios fonctionnent comme prévu. Même si j'ai fermé une instance à l'intérieur de la fenêtre using(...) le fichier est "déverrouillé".

Q1 : Je me demande si quelque chose pourrait se produire en cas de plantage de l'application, de sorte que les autres instances se voient refuser l'accès au fichier (pendant un certain temps ?).

Q2 : Que se passe-t-il en cas de perte de la connexion réseau lors de l'ouverture d'un fichier ?

Q3 : Y a-t-il des raisons d'utiliser (en plus) l'option FileStream.Lock() y Déverrouiller() pour verrouiller et déverrouiller explicitement un fichier ?

Q4 : Le système des serveurs nécessite-t-il quelque chose pour que cette façon de verrouiller les fichiers fonctionne ?

Q5 : Y a-t-il d'autres points auxquels je dois réfléchir ?

Answer 1

... tout peut arriver lors d'un plantage d'application

Le verrou est instantanément levé lorsque le système d'exploitation nettoie les éclats et ferme tous les fichiers qui n'ont pas été fermés par l'application.

Que se passe-t-il en cas de perte de la connexion réseau lors de l'ouverture d'un fichier ?

Vous obtiendrez une exception d'exécution, IOException. Récupérable uniquement en rétablissant la connexion réseau et en rouvrant le fichier. Les réseaux sont généralement assez fiables pour ne pas effectuer cette opération automatiquement.

Y a-t-il des raisons d'utiliser (en plus) la fonction FileStream.Lock() ...

Non. Ces fonctions verrouillent le fichier données au lieu de l'accès aux fichiers. C'est le genre de chose que ferait un moteur de base de données. Cela ne s'applique jamais à un fichier texte puisqu'il s'agit de flux et que vous ne connaissez jamais la position exacte d'une ligne de texte dans le fichier.

Le système des serveurs exige-t-il quelque chose ...

Non, c'est intégré au système d'exploitation.

Y a-t-il d'autres points auxquels je dois réfléchir ?

Vous devriez probablement penser davantage à écrire le fichier, quelqu'un va devoir le faire. L'utilisation de FileShare.None est simple mais tend à être un peu grossière sur les fichiers texte, en particulier s'il s'agit de fichiers journaux qui restent toujours ouverts. Il est techniquement possible pour une application de lire un fichier en cours d'écriture. Cela a tendance à bien se passer puisque les fichiers texte ne sont jamais qu'ajoutés. Il faut utiliser FileShare.Read dans l'application qui écrit le fichier et FileShare.ReadWrite dans l'application qui lit le fichier. Ce n'est pas une faute de frappe.

Answer 2

Le verrouillage des fichiers auquel vous faites référence est effectué au niveau du système d'exploitation. Donc si votre application se plante, fait une erreur, etc., elle libérera le fichier. Cela s'applique à Q1 et Q2 (bien que Q2 dépende de la topologie du réseau et du stockage de secours). Attention, le verrouillage d'un fichier peut causer d'étranges problèmes de performance avec un stockage secondaire dont la mise en mémoire tampon est activée. Q3, le verrouillage et le déverrouillage dont il est question ici n'est pas un verrouillage de fichier, mais des octets dans un fichier. Il s'agit d'un concept complètement différent et il VA provoquer un comportement bizarre sur un stockage de type NAS. Q4, comme je l'ai déjà dit, c'est un concept de niveau OS. Q5. Pensez à une meilleure façon de gérer cela, l'utilisation d'un fichier est un concept relativement ancien, cependant, le partage d'un fichier entre plusieurs ordinateurs sur un réseau, IMHO, demande un comportement bizarre. Le stockage moderne des fichiers n'est pas adapté à ce concept et, avec la mise en mémoire tampon, la latence et la sécurité, cela devient un défi. Évitez-le si vous le pouvez. Dans le cas contraire, assurez-vous d'optimiser votre application pour qu'elle ouvre le fichier, écrive, ferme et vide le flux aussi rapidement que possible.