Windows 文件共享:为什么有时新创建的文件在一段时间内不可见? [英] Windows file share: why sometimes newly created files aren't visible for some period of time?

问题描述

我们遇到了非常奇怪的问题，让我们发疯了.有时，我们的文件共享 PC 上新创建的文件会在一段时间内不存在".要重现问题，您应该至少拥有两台计算机，将它们称为 alpha 和 beta.在 beta PC (\\beta\share\bug) 上创建文件共享并从 alpha PC 运行此 PowerShell 脚本:

We were faced with very strange issue that made us crazy. Sometimes newly created files on our File Share PC were "absent" for some period of time. To reproduce a problem you should have at least two computers, call them alpha and beta. Create file share on beta PC (\\beta\share\bug) and run this PowerShell script from alpha PC:

param(
  $sharePath="\\beta\share\bug"
)
$sharePC = ($sharePath -split '\\')[2]
$session = New-PSSession -ComputerName $sharePC
$counter = 0
while ($true) {
  $fileName = $sharePath + "\$counter.txt"
  Invoke-Command -Session $session -ScriptBlock {
    param(
      $fileName
    )
    "" > $fileName
  } -ArgumentList $fileName
  if (Test-Path $fileName) {
    Write-Host "File $fileName exists" -fore Green
  } else {
    Write-Host "!!! File $fileName does NOT exist!" -fore Red
  }

  $counter = $counter + 1
  Start-Sleep 2
}

启动此脚本后，您应该能够看到以下消息:

After starting this script you should be able to see these messages:

File \\beta\share\bug\1.txt exists
File \\beta\share\bug\2.txt exists
...

现在:打开 cmd.exe 并运行以下命令:

And now: Open cmd.exe and run this command:

如果存在 \\beta\share\bug\foo.txt echo 1

在大约 10 秒后，您将看到以下消息:

After this during approx 10 seconds you'll see following messages:

!!! File \\beta\share\bug\3.txt does NOT exist!
!!! File \\beta\share\bug\4.txt does NOT exist!

我们发现错误是由枚举正在创建新文件的共享目录引起的.在 Python 中调用 os.listdir('//beta/share/bug') 来重现错误.在 C# 中:Directory.GetDirectories(@"\\beta\share\bug").您甚至可以简单地通过 shell 导航到共享目录并调用 ls 或 dir.

We've discovered that bug is caused by enumerating shared directory where new files are being created. In Python call os.listdir('//beta/share/bug') to reproduce a bug. In C#: Directory.GetDirectories(@"\\beta\share\bug"). You can even simply navigate to share directory by shell and call ls or dir.

在 Windows Server 2008 R2

注意，alpha PC 上不能在 Windows Explorer 中实时观看目录内容，因为如果你在 Explorer 中打开这个目录就不会出现 bug！因此，请确保在尝试重现错误之前关闭所有此类窗口.每次脚本重新启动后，您应该手动从共享中删除所有已创建的文件(因为脚本相当愚蠢并且总是从 0.txt 开始).

Note, that you cannot watch directory content on alpha PC in Windows Explorer in real time, because if you open this directory in Explorer bug would not occur! So ensure to close all such windows before attempts to reproduce a bug. After each script restart you should manually remove all already created files from share (because script is rather stupid and always starts from 0.txt).

我们目前有两种解决方法来解决这个问题:

We currently have 2 workarounds for this issue:

1. 如果客户端看到这种情况，它会在有问题的目录中创建一些临时文件 - 在这些文件神奇地出现之后.
2. 禁用 SMB 2.0:http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

有没有人发现过类似的问题并且可以解释它为什么会发生以及如何正确修复"它?

Does anybody have ever discovered similar problem and can explain why it occurs and how "correctly fix" it?

谢谢

推荐答案

我遇到了类似的问题，最终我找到了这个问题的原因.具体问题是 SMB2 目录缓存，它是 SMB2 客户端重定向器缓存组件:

I was experiencing a similar problem and, eventually, I found the cause of this issue. The specific problem is the SMB2 Directory Cache, which is one of the SMB2 Client Redirector cache components:

这是客户端执行的最近目录枚举的缓存.客户端应用程序发出的后续枚举请求以及目录中文件的元数据查询可以从缓存中得到满足.客户端还使用目录缓存来确定目录中是否存在文件，并使用该信息来防止客户端重复尝试打开服务器上已知不存在的文件.此缓存可能会影响在多台计算机上运行的分布式应用程序访问服务器上的一组文件 - 其中应用程序使用带外机制相互发送有关修改/添加/删除服务器上文件的信号.

This is a cache of recent directory enumerations performed by the client. Subsequent enumeration requests made by client applications as well as metadata queries for files in the directory can be satisfied from the cache. The client also uses the directory cache to determine the presence or absence of a file in the directory and uses that information to prevent clients from repeatedly attempting to open files which are known not to exist on the server. This cache is likely to affect distributed applications running on multiple computers accessing a set of files on a server – where the applications use an out of band mechanism to signal each other about modification/addition/deletion of files on the server.

这个美妙的小缓存的默认值是 10 秒，这会产生您所看到的行为.当您的代码向系统询问该目录/文件时，它会得到缓存结果，这是 10 秒前的结果，因此它说该文件不存在.将 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters\DirectoryCacheLifetime (DWORD) 设置为 0 的值将禁用缓存并解决文件不存在的问题.令人惊讶的是，此更改不需要需要重新启动客户端计算机！这也将允许您保持 SMB2 启用，出于多种原因，这应该比强制 SMB1 更好.

The default value for this wonderful little cache is 10 seconds, which is producing the behavior you're seeing. When your code asks the system about that directory/file it's getting the cached result, which is 10 seconds old, so it says the file does not exist. Setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters\DirectoryCacheLifetime (DWORD) to a value of 0 will disable the cache and resolve the file doesn't exist issue. Surprisingly this change does not require a restart of the client machine! This will also allow you to keep SMB2 enabled, which should be better for a number of reasons vs. forcing SMB1.

此外，当有问题的共享在 Windows 资源管理器中打开时，不会使用缓存，因为打开它会告诉系统绕过缓存以保持实时取景.但是，通过代码修改共享中的某些内容不会.

Furthermore, the cache is not used when the share in question is opened in Windows explorer, as having it open tells the system to bypass the cache to keep a live view going. Modifying something in the share via code, however, does not.

我认为整个问题在 Windows 2008 R2/7 及更高版本中已解决，但我不能完全确认. 这仍然是现代版本的 Windows 中的问题.有关详细信息，请参阅下面的评论.

I think this whole issue is fixed in Windows 2008 R2/7 and higher, but I cannot absolutely confirm it. This is still an issue in modern versions of Windows. See the comments below for details.

这篇关于Windows 文件共享:为什么有时新创建的文件在一段时间内不可见?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！