Linux Samba 共享上的新文件:现在你看不到我,现在你可以看到我

Linux Samba 共享上的新文件:现在你看不到我,现在你可以看到我

当文件上传到我们的服务器时,我们必须对其进行一些处理以允许或拒绝它。有些文件需要在 Windows 机器中打开(OpenXml Sdk 性能原因)。
我们的 Web 服务器在 Linux 机器中运行。Linux 中还有一个 samba 共享。
上传文件时,php 会将其复制到该共享文件夹,以便每个人都可以访问新文件。复制完成后,php 会向 Windows 机器发送一条消息,内容为: Scan //Linux.Share.Ip/SharedFolder/FileJustUploaded.rtf

但是我们得到了一个文件未找到!

如果我们轮询文件系统,该文件会在短时间(几毫秒到几秒)后按预期出现在共享文件夹中。

让共享文件夹为 /opt/sharedFolder
Linux Ip: 192.168.1.10
Windows Ip : 192.168.1.11

最初,php 将文件复制到 /opt/sharedFolder。
为了尝试让 samba意识到的创建新文件时,我们已经在 /mnt/sharedFolder 中挂载了我们自己的共享文件夹。

mount -t cifs //192.168.1.10/sharedFolder /mnt/sharedFolder

因此 php 将新上传的内容移动到 /mnt/sharedFolder,然后将消息发送到 windows 请求Scan //192.168.1.10/SharedFolder/FileJustUploaded.rtf

没有运气 :(

因此,如果我理解正确的话,扫描消息会让 Windows 在 Samba 广播该文件的存在之前向 Samba 请求该文件,因此出现错误。

我们可以做些什么来防止这种情况发生吗?
我们可以改变一些东西来防止这种情况发生吗?

有没有“正确的方法/最佳实践”来做到这一点?我的意思是,使用 DFS 或其他文件系统(在 Windows 和 Linux 中可用)可以解决这个问题?

非常欢迎任何建议。

答案1

看来 Windows 维护着文件和目录的缓存

随着 Windows Vista® 和 Windows Server 2008 中 SMB 2.0 的发布,实施了三个文件元数据缓存,以加快返回最近访问的文件和目录信息。这些缓存还减少了客户端与 SMB 服务器进行常见文件浏览操作所需的交互次数。这在客户端通过低带宽或高延迟连接浏览网络文件目录等场景中非常有用。对于常见的网络文件浏览场景,默认值已足够,不应更改。更改这些缓存超时值可能会对许多网络文件场景产生重大的性能影响。由于每个缓存都旨在减少 SMB 服务器请求的数量,因此它们不仅在客户端响应时间评估中很重要,而且在整体 SMB 服务器可扩展性和性能中也很重要。

使用适当的注册表项将延迟从 10 秒更改为 0 似乎可以解决问题。现在客户端在每次请求时都会列出来自服务器的文件,而不是在不检查服务器的情况下回答 FileNotFount... 只是因为十秒前它还不存在。

相关内容