Question

J'ai trouvé que si vous ouvrez un fichier qui se trouve sur le serveur 32 bits dans un dossier partagé à partir d'un 64 bit windows 7 machine, lire, verrouiller puis ouvrez-le à nouveau. Lorsque vous fermez toutes les poignées ouvertes le fichier reste effectivement ouvert.

Les étapes exactes sont:

  1. Placer un fichier qui se situe entre 7000 et 10000 octets de long dans un dossier partagé sur une machine Windows 32 bits, nous utilisons Windows Server 2003.

  2. Compile le code suivant pour Win32 pour qu'il fonctionne sous WOW64. S'il vous plaît noter que j'ai manqué try..finally, déclarations, etc. pour plus de simplicité.
    (Voir fragment de code ci-dessous, un bug StackOverflow ne code format pas correctement quand il se trouve dans une liste)

  3. Exécuter l'application sur une machine Windows 64 bits. le fichier doit être sur une machine 32 bits, nous utilisons Windows Server 2003, le bug ne se produit pas si le fichier est sur un serveur 64 bits.

  4. Mettre fin à votre application.

  5. Si maintenant vous ouvrez le gestionnaire de l'ordinateur sur le serveur (contrôle Configuration-> gestion informatique) et regarder les fichiers ouverts dans le dossier de partage où se trouve votre fichier, vous verrez que votre fichier est toujours ouvert.

Voici le code:

procedure CauseFileLockBug(FileName: PChar);
var
  FileHandle1: LongInt;
  FileHandle2: LongInt;
  Buffer: Pointer;
  BytesRead: Cardinal;
begin
  FileHandle1 := CreateFile(
    FileName, 
    GENERIC_READ or GENERIC_WRITE, 
    FILE_SHARE_READ or FILE_SHARE_WRITE, 
    nil, 
    OPEN_EXISTING, 
    FILE_FLAG_RANDOM_ACCESS, 
    0);

  if FileHandle1 > 0 then
  begin
    try
      GetMem(Buffer, 1);

      try
        if ReadFile(FileHandle1, Buffer^, 1, BytesRead, nil) then
        begin
          if LockFile(FileHandle1, 6217, 0, 1, 0) then
          begin
            try
              FileHandle2 := CreateFile(
                FileName, 
                GENERIC_READ or GENERIC_WRITE, 
                FILE_SHARE_READ or FILE_SHARE_WRITE, 
                nil, 
                OPEN_EXISTING, 
                FILE_FLAG_RANDOM_ACCESS, 
                0);

              if FileHandle2 > 0 then
              begin
                CloseHandle(FileHandle2);
              end;
            finally
              UnLockFile(FileHandle1, 6217, 0, 1, 0);
            end;
          end;
        end;
      finally
        FreeMem(Buffer);
      end;
    finally
      CloseHandle(FileHandle1);
    end;
  end;
end;

Le problème se ne se produit pas si vous utilisez le drapeau FILE_FLAG_NO_BUFFERING lors de l'ouverture du fichier la deuxième fois ou si vous ne lisez pas le fichier avant de le verrouiller.

Quelqu'un at-il remarqué avant ou savoir comment le résoudre, sans utiliser le FILE_FLAG_NO_BUFFERING? S'il vous plaît pas que cela ne se produit que lorsqu'un client Windows 64 bits ouvre un fichier de cette manière sur une machine Windows 32 bits, il ne se produit pas avec 32 bits ou 64T à 64 ans.

Était-ce utile?

La solution

Ok Problème résolu.

On dirait Nod32 x64 est l'origine du problème. Ajout de tous les chemins possibles dans le dossier (tous les chemins du réseau et des lecteurs mappés) à la liste des exclusions avec caractères génériques *, puis redémarrer le PC a fixé il.

En tout cas merci pour votre aide.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top