Question

I have found that if you open a file that resides on 32 bit server in a share folder from a 64 bit windows 7 machine, read it, lock it and then open it again. When you close all open handles the file actually remains open.

The exact steps are:

1. Place a file that is between 7000 and 10000 bytes long in a shared folder on a 32 bit windows machine, we are using Windows Server 2003.

2. Compile the following code for Win32 so that it runs under WOW64. Please note that I’ve missed out try..finally, declarations, etc for simplicity.
   (see code fragment below; a StackOverflow bug does not format code correctly when it is inside a list)

3. Run the application on a 64 bit windows machine. the file must be on a 32 bit machine, we use windows server 2003, the bug does not occur if the file is on a 64 bit server.

4. Terminate your application.

5. If you now open up the computer manager on the server (control panel->computer management) and look at the opened files in the share folder where your file resides you will see that your file is still open.

This is the 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;

The problem goes does not occur if you use the FILE_FLAG_NO_BUFFERING flag when opening the file the second time or if you do not read the file before locking it.

Has anyone noticed this before or know how to solve it, without using the FILE_FLAG_NO_BUFFERING? Please not that it only happens when a 64 bit windows client opens a file in this way on a 32 bit windows machine, it does not occur with 32 to bit or 64t to 64.

Answer 1

Ok Problem solved.

Seems like Nod32 x64 was causing the issue. Adding all possible paths into the folder (all network paths and mapped drives) to the exclusions list with wildcard * and then rebooting the PC has fixed it.

Anyway thanks for your help.