proNovell

Наблюдаю странную картину - клиент Win2000/XP+Cl32_4.91SP3 открывает некий текстовый файлик на сетевом диске (NW6.5+SP5) на чтение (н-р, F3 в FAR-е) и сразу же выходит из просмотра файла (Escape-ом). Но если тут же посмотреть статус этого файла из консольного MONITOR.NLM или утилитой OPENFILE.EXE, то некоторое время - примерно секунд 30 - этот файл ещё показывается как открытый. Что это за ерунда?:

Код: Выделить всё

U:\PUBLIC\LSCRIPT>openfile NKOCOMM.SCR /d

Connections using NKOS/SYS:PUBLIC/LSCRIPT/NKOCOMM.SCR

  38 Admin (Administrator)

1 connection

1 file, 1 connection

Обратил на это внимание, когда несколько раз увидел тайм-ауты по op-lock-ам для этого файла (реально это login script, я его традиционно include-ом включаю, так работает уже больше десяти лет):

Код: Выделить всё

5/02/2008  10:38:51 :    COMN-3.24-592  [nmID=F000A]                         
    Station 668 (task 4) timed out waiting for an op-lock on file NKOCOMM.SCR
    held by station 664.

Это что, для простого чтения оп-лок включается? Зачем?!

Насколько я знаю, именно far именно в режиме просмотра сетевых дисков использует функцию "слежения" и при изменении файла считывает изменившийся кусок. Например, таким образом удобно в far`e отслеживать логи. Открыл по f3, стал в конец и видишь имитацию команды tail -f.
Возможно, lock используется именно для этого.

Ковалев Артем писал(а):Насколько я знаю, именно far именно в режиме просмотра сетевых дисков использует функцию "слежения" и при изменении файла считывает изменившийся кусок. Например, таким образом удобно в far`e отслеживать логи. Открыл по f3, стал в конец и видишь имитацию команды tail -f.
Возможно, lock используется именно для этого.

То, что far можно в режиме tail -f использовать - это я знаю и использую. Но блокировки по оп-локам возникали просто при логине, когда входящий в сеть клиент открывал файл логин скрипта для исполнения - вот это непонятно, с какой радости вылезло. В общем, пока сделал стандартный ход:

SET LEVEL 2 OPLOCKS ENABLED = OFF
SET CLIENT FILE CACHING ENABLED = OFF

потому что пока ещё не всех клиентов проапгрейдили до 4.91. В http://wiki.novell.com/index.php/OpLocks_on_NetWare говорится, что необходимым условием работы является NW6.5SP4a и новее + клиент 4.91SP2 и новее на всех рабочих станциях. У меня пока второе условие невыполнено, вот проапгрейдим всех клиентов - тогда попробую опять оп-локи включить.

Сергей Дубров писал(а):

Ковалев Артем писал(а):Насколько я знаю, именно far именно в режиме просмотра сетевых дисков использует функцию "слежения" и при изменении файла считывает изменившийся кусок. Например, таким образом удобно в far`e отслеживать логи. Открыл по f3, стал в конец и видишь имитацию команды tail -f.
Возможно, lock используется именно для этого.

То, что far можно в режиме tail -f использовать - это я знаю и использую. Но блокировки по оп-локам возникали просто при логине, когда входящий в сеть клиент открывал файл логин скрипта для исполнения - вот это непонятно, с какой радости вылезло. В общем, пока сделал стандартный ход:

SET LEVEL 2 OPLOCKS ENABLED = OFF
SET CLIENT FILE CACHING ENABLED = OFF

потому что пока ещё не всех клиентов проапгрейдили до 4.91. В http://wiki.novell.com/index.php/OpLocks_on_NetWare говорится, что необходимым условием работы является NW6.5SP4a и новее + клиент 4.91SP2 и новее на всех рабочих станциях. У меня пока второе условие невыполнено, вот проапгрейдим всех клиентов - тогда попробую опять оп-локи включить.

Я сижу строго на клиентах 4.90SP2, поскольку они последние, кто нормально работает с Zen4. Сервера от 5.1SP7 до 6.5SP6 - проблем с блокировками не бывает. Тут что-то не то.