Когда файл загружается на наш сервер, мы должны немного поработать с ним, чтобы разрешить или отклонить его. Некоторые файлы необходимо открывать в окне Windows (из соображений производительности OpenXml Sdk).
Наш веб-сервер работает под управлением Linux. В Linux тоже есть доля самбы.
Когда файл загружен, 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.
В попытке сделать самбу осведомленный При создании нового файла мы смонтировали в / 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 запрашивать файл у самбы до того, как самба передаст информацию о существовании этого файла, отсюда и ошибка.
Можем ли мы сделать что-нибудь, чтобы этого не произошло?
Можем ли мы что-то изменить, чтобы этого не произошло?
Есть ли «правильный способ / лучшие места» для этого? Я имею в виду, что использование DFS или другой файловой системы (доступной в Windows И Linux) исправит это?
Любые предложения более чем приветствуются.
Кажется, что в окнах есть кеш для файлов и каталогов
С выпуском SMB 2.0 в Windows Vista® и Windows Server 2008 были реализованы три кэша метаданных файлов для ускорения возврата информации о файлах и каталогах, к которым последний раз осуществлялся доступ. Эти кеши также сокращают количество взаимодействий, необходимых клиенту с сервером SMB для обычных операций просмотра файлов. Это имеет значение в таком сценарии, как клиент просматривает сетевой каталог файлов при подключении через соединение с низкой пропускной способностью или высокой задержкой. Для обычных сценариев просмотра сетевых файлов достаточно значений по умолчанию, и их не следует изменять. Изменение этих значений тайм-аута кэша может иметь значительные последствия для производительности во многих сценариях работы с сетевыми файлами. Поскольку каждый из этих кешей предназначен для уменьшения количества запросов к серверу SMB, они важны не только для оценки времени ответа клиента, но и для общей масштабируемости и производительности сервера SMB.
Изменение задержки с 10 секунд на 0 с помощью подходящего раздела реестра, похоже, решает проблему. Теперь клиент перечисляет файлы с сервера по каждому запросу вместо ответа на FileNotFount без проверки сервера ... только потому, что десять секунд назад его там не было.