Re: Problem z programem sieciowym pod WinXP ....

Autor: JLPicard <no_mail_at_4spammers.com>
Data: Sun 17 Oct 2004 - 14:57:57 MET DST
Message-ID: <cktqft$sn7$1@nemesis.news.tpi.pl>
Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original

"Wodzu" <wodzub16.spams.dead@pf.pl> wrote in message
news:cqnqimjw0e2o$.1os44ms55wc8f.dlg@40tude.net...
> Dnia Sat, 16 Oct 2004 00:23:35 +0200, JLPicard napisał(a):
>
>> Problem "stary" jak windows NT :)
>> Rozwiązaniem problemu jest wyłączenie oplock`ów.
>>
>> Poszukaj w google ... :)
>
> Mógłbyś rozwinąć temat? Używam GPRSu - googlowanie mi się nie kalkuluje, a
> temat mnie bardzo interesuje. Coś dzisiaj słyszałem na ten temat. Zdaje
> się, że wyłączenie oplocków stwarza inne problemy?

Heh lenistwo nie zna granic ;)

Windows NT use of RFCB Caching (caching file handles) and Opportunistic
locking can create data corruption in Solution System 2 or CaseBASE.
Microsoft introduced an operating system feature in Windows NT that caches
file handles called RFCB Caching. This was done in order to increase the
file handling performance of specific kinds of Windows based applications on
an NT server (such as client/server based applications). This feature can
cause problems in traditional DOS based database programs that use Standard
File and Record Locking. NT Server service caches file handles (RFCBs)
associated with files it has opened on behalf of a client (workstation)
request. Although write requests proceed normally, close requests are
acknowledged by the server, but are buffered from the file system. This is
intended to optimize response time to repeated open/close operations
performed by clients. Opportunistic Locking (oplock) is an optimization that
is a logical extension of the way a client caches its own file close request
and relies on the server to arbitrate future requests for file access by
other clients, rather than allowing the application to actually close it's
own file handles. In many situations, Oplocks must also be disabled for
compatibility purposes. Because of Opportunistic Locking's relationship with
file closes, RFCB Caching and Opportunistic Locking go hand-in-hand.
Microsoft presumes you will not be running traditional DOS database
applications on your new server and as a result, both of these potentially
data corrupting features are activated by default upon installation of
Windows NT Server. An obvious sign that a file is being held open is the
reported file size may be zero. In Control Panel, the Server option displays
open files, when in fact, they are only open by the Server service in a
cached mode. Other signs may include sharing violations or data and index
file corruption, or at least an apparent lack of synchronization between the
data at various workstations. Solution System 2 and CaseBASE rely on the
file handles actually being closed. Local file operations are not serviced
by the server and are not subject to RFCB Caching. Verify (and correct, if
necessary) these NT Server parameters:
\HKey_Local_Machine\System\Current Control
Set\Services\LanmanServer\Parameters
EnableOpLockForceClose=1 (DWORD)
EnableOpLocks=0 (DWORD)
CachedOpenLimit=1 (DWORD)

Problem dotyczy wiekszości aplikacji dos`owych na bazach plikowych w
windows`ach NT, 2000, XP, 2003.
Received on Sun Oct 17 15:00:31 2004

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Sun 17 Oct 2004 - 15:42:04 MET DST