comportement de verrouillage est différent via des partages réseau

Question

J'ai essayé de verrouiller un fichier afin que d'autres services clonés ne peuvent pas accéder au fichier. J'ai lu le fichier, puis déplacez le fichier lorsque vous avez terminé. Le déplacement est autorisé en utilisant FileShare.Delete.

Cependant, dans les tests plus tard, nous avons constaté que cette approche ne fonctionne pas si nous regardons un partage réseau. J'apprécie mon approche peut ne pas avoir été le meilleur, mais ma question spécifique est:

Pourquoi la démo ci-dessous le travail contre le fichier local, mais pas contre le fichier réseau?

Le plus spécifique, vous pouvez être le meilleur, comme je l'ai trouvé très peu d'informations dans mes recherches qui indiquent les partages réseau se comportent différemment des disques locaux.

string sourceFile = @"C:\TestFile.txt";
string localPath = @"C:\MyLocalFolder\TestFile.txt";
string networkPath = @"\\MyMachine\MyNetworkFolder\TestFile.txt";

File.WriteAllText(sourceFile, "Test data");

if (!File.Exists(localPath))
    File.Copy(sourceFile, localPath);

foreach (string path in new string[] { localPath, networkPath })
{
    using (FileStream fsLock = File.Open(path, FileMode.Open, FileAccess.ReadWrite, (FileShare.Read | FileShare.Delete)))
    {
        string target = path + ".out";
        File.Move(path, target); //This is the point of failure, when working with networkPath

        if (File.Exists(target))
            File.Delete(target);
    }

    if (!File.Exists(path))
        File.Copy(sourceFile, path);
}

EDIT: Il convient de mentionner que si vous souhaitez déplacer le fichier d'un partage réseau, à un autre partage réseau alors que le verrou est en place, cela fonctionne. Le problème ne semble se produire lors du déplacement d'un fichier dans les même partage de fichiers pendant qu'il est verrouillé.

Answer 1

Je crois System.IO.File.Open () cartes à la fonction API Win32 CreateFile (). Dans la documentation de Microsoft pour cette fonction [ http: // msdn .microsoft.com / fr-fr / bibliothèque / aa363858 (v = vs.85) .aspx ], il mentionne ce qui suit:

  

Windows Server 2003 et Windows XP / 2000: Une violation de partage se produit si une tentative est faite d'ouvrir un fichier ou un répertoire pour la suppression sur un ordinateur distant lorsque la valeur du paramètre dwDesiredAccess est l'indicateur d'accès SUPPRIMER (0x00010000) OR » ed avec un autre indicateur d'accès et le fichier distant ou le répertoire n'a pas été ouvert avec FILE_SHARE_DELETE. Pour éviter la violation de partage dans ce scénario, ouvrez le fichier distant ou un répertoire avec l'accès SUPPRIMER droite uniquement, ou appelez DeleteFile sans ouvrir le fichier ou le répertoire pour la suppression.

D'après cela, vous devez passer SUPPRIMER comme paramètre FileAccess à IO.File.Open (). Malheureusement, l'énumération SUPPRIMER n'a pas été inclus en option.

Ce problème ne concerne que Windows 2003 et versions antérieures. J'ai testé votre code sur Windows 2008 R2 SP1, et il fonctionne très bien. Il est donc possible que cela fonctionne également sur Windows 2008 ainsi.