0

When a file is uploaded to our server, we have to do some work on it to allow or reject it. Some files need to be opened in a Windows box (OpenXml Sdk performance reasons).
Our web server runs in a Linux box. There is also a samba share in Linux.
As a file is uploaded, php copies it to that shared folder so the new file can be accessed by everyone. When the copy is done, php sends a message to the Windows machine saying: Scan //Linux.Share.Ip/SharedFolder/FileJustUploaded.rtf

But we get a File Not Found !

If we poll the filesystems, the file appears in the shared folder as expected after short period of time (miliseconds to couple of seconds).

Let the shared folder be /opt/sharedFolder
Linux Ip: 192.168.1.10
Windows Ip : 192.168.1.11

At first, php was copying the files into /opt/sharedFolder.
In a try to make samba aware of the creation of the new file, we have mounted in /mnt/sharedFolder our own shared folder.

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

consequently php moves new uploads to /mnt/sharedFolder and then send the message to windows requesting Scan //192.168.1.10/SharedFolder/FileJustUploaded.rtf

No Luck :(

So, if i am getting this right, the Scan message makes windows request the file to samba before samba has broadcasted the existence of that file, hence the error.

Can we make something to prevent this from happening?
Can we change something to prevent this from happening?

Is there a "right way/best prectices" of doing this? I mean, using DFS or another filesystem (available in windows AND Linux) would fix this ?

Any suggestions are more than welcome.

Nomada
  • 101
  • 2

1 Answers1

0

It seems that windows mantains a cache for files and directories

With the release of SMB 2.0 in Windows Vista® and Windows Server 2008, three file metadata caches were implemented to speed up the return of the most recently accessed file and directory information. These caches also reduce the number of interactions a client requires with a SMB server for common file browsing operations. This has value in a scenario such as a client browsing a network file directory while connected via a low bandwidth or high latency connection. For common network file browsing scenarios, the default values are sufficient and should not be altered. Changing these cache timeout values can have significant performance implications to many network file scenarios. As each of these caches is designed to reduce the number of SMB server requests, they are important not only in client response time evaluation, but also in overall SMB server scalability and performance.

Changing the delay from 10 seconds to 0 using appropiate registry key seems to fix the issue. Now client lists files from server on every request instead of answering FileNotFount without checking the server... just because ten seconds ago it wasn't there.

Nomada
  • 101
  • 2