我发现,如果您打开一个从64位Windows 7计算机中的共享文件夹中驻留在32位服务器上的文件,请阅读,锁定,然后再次打开。当您关闭所有打开时,文件实际上保持打开状态。

确切的步骤是:

  1. 在32位Windows计算机上的共享文件夹中,将一个长度在7000到10000字节之间的文件放置,我们正在使用Windows Server 2003。

  2. 编译WIN32的以下代码,以使其在WOW64下运行。请注意,为简单起见,我错过了尝试。
    (请参阅下面的代码片段;堆栈流bug在列表中时无法正确格式化代码)

  3. 在64位Windows机器上运行该应用程序。该文件必须在32位计算机上,我们使用Windows Server 2003,如果文件在64位服务器上,则不会发生错误。

  4. 终止您的申请。

  5. 如果您现在打开服务器上的计算机管理器(控制面板 - >计算机管理),并查看“共享文件夹”中的打开文件,您将看到您的文件仍然打开。

这是代码:

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;

如果您在第二次打开文件时或在锁定文件之前未读取文件时,就不会发生问题,如果您使用file_flag_no_buffering标志。

是否有人在不使用file_flag_no_buffering的情况下注意到了这一点或知道如何解决?请不要只有只有在32位Windows机器上以这种方式打开文件时,就不会发生这种情况,它不会发生32至Bit或64t至64。

有帮助吗?

解决方案

好的问题解决了。

似乎NOD32 X64正在引起问题。将所有可能的路径添加到文件夹中(所有网络路径和映射驱动器)中使用通配符 *的排除列表,然后重新启动PC已将其修复。

无论如何,感谢您的帮助。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top