Клиенты Windows не будут обновлять файл самбы Linux локально, если чтение файла с интервалом <= 10 секунд

Если у меня Windows-клиент читает файл в общей папке Linux smb с интервалом <= 10 секунд, Windows-клиент будет показывать неверную (кэшированную?) Информацию об этом файле.

Я воспроизвел это на нескольких системах.

Пример шагов для воспроизведения:

1) настроить общий доступ к Linux в samba - для этого примера используйте Debian и установите samba. пример:

sudo mkdir /test
sudo chmod 777 /test

дополнение smb.conf:

[test]    
read only = no    
locking = no    
path = /test/    
guest ok = yes

2) Сопоставьте этот каталог как диск в клиенте Windows (этот тест будет использовать L :)

3) создать файл с текстом на сервере samba

nano /test/test.txt
ORIGINAL

4) создать простой пакетный файл на машине Windows, чтобы просматривать файл каждые 5 секунд:

copy con test.bat
@echo off
cls
:1
type L:\test.txt
timeout 5
goto 1

5) запустить пакетный файл, он должен показывать ОРИГИНАЛ каждые 5 секунд.

6) на сервере Linux измените содержимое файла

nano /test/test.txt
CHANGED

7) просматривать запущенный пакетный файл в Windows, он будет по-прежнему говорить «ОРИГИНАЛ» каждые пять секунд, а не «ИЗМЕНЕНО», как в реальном файле.

8) прервите пакетный файл и подождите ~ 15 секунд, ИЛИ измените время ожидания на что-то> 10 секунд, и оно будет обновлено должным образом.

Надеюсь, я объяснил и обрисовал в общих чертах, как проверить это достаточно.

Может кто-нибудь воспроизвести это поведение и / или предложить, как это исправить?

,

,

,

НОТЫ:

Linux Client> Linux SMB Host показывает правильное содержимое файла.

Windows Client> Windows SMB Host показывает правильное содержимое файла.

В частности, это Windows Client> Linux SMB Host, который не показывает правильное содержимое файла с интервалом обновления <= 10 секунд.

Все версии Windows, которые я тестировал (Win7, Win10, Server2016), демонстрируют одинаковое поведение.

Я также протестировал различные протоколы на моей общей папке samba «NT1, SMB2, SMB3», и они не меняют поведение.

ПРИМЕЧАНИЕ. Я полагаю, что это, скорее всего, проблема с Windows, но я не получил ни одного ответа ни по technet, ни по superuser в течение недели. Это должно быть довольно легко проверить, кто-нибудь может подтвердить это поведение или заявить иначе?

Значения по умолчанию для соответствующих настроек:

• oplocks = yes
• kernel oplocks = no

(См. Документацию Samba smb.conf )

Вы можете отключить оплоки, как в другом ответе .

В качестве альтернативы, если вы используете операционную систему Linux с современным ядром (2.4 или новее), вы можете оставить oplocks = yesи вместо этого добавить строку, smb.confчтобы включить оплокировку ядра. Согласно разделу ядра (S) в документации:

Поддержка блокировок ядра позволяет прерывать блокировку Samba всякий раз, когда локальный процесс UNIX или операция NFS обращается к файлу, который был заблокирован smbd (8). Это обеспечивает полную согласованность данных между SMB / CIFS, NFS и локальным доступом к файлам.

Когда oplocksи kernel oplocksоба включены, вы должны получить хорошую производительность (от кэширования) и аннулирование кэша при обновлении файлов.

Чтобы включить оплокировку ядра, добавьте эту строку в файл конфигурации Samba:

kernel oplocks = yes

Я решил это, поместив

oplocks = False

в моем файле smb.conf в настройках общего ресурса.

https://www.samba.org/samba/docs/old/Samba3-HOWTO/locking.html#id2615926