TIP: Click on subject to list as thread! ANSI
echo: lan
to: MIKE BILOW
from: LEE ARONER
date: 1997-12-30 23:50:00
subject: Win95 no dialogs ?

MB> LEE ARONER wrote in a message to GEORGE FLIGER:
 LA> AFAIK, the latest version of Client32 still defaults to "ON" 
 LA> for Packet Burst and Opportunistic Locking, which will destroy 
 LA> server files of any application (mostly databases) that make 
 LA> DOS file locking calls across the wire.
MB> I can't see any reason that packet burst should cause this sort of 
roblem
  > unless the drivers for your NIC are buggy.  Opportunistic locking is also 
not
  > inherently incompatible with DOS file locking, but the applications must 
be
  > able to cope with it.  For some older DOS applications, opportunistic 
locking
  > does have to be disabled.
   I used to support a Windows application called ECCO. An amazing 
   piece of work, one of it's features was a remarkably easy way to 
   share data files in a workgroup paradigm. The sharing mechanism 
   used data files and control files which were placed in a mutually 
   available network directory. The control file was opened and 
   flags were read at approximately 5 second intervals by all 
   connected clients (in turn, obviously). If a client made an 
   update to the data file, the control file was opened and the data 
   was appended to the (network) control file, the flags were set 
   appropriately, and the new/changed data was then downloaded to 
   the other clients each in it's turn.
   Obviously, the control file depended entirely on file locking for 
   it's integrity. If the requested locks are not observed, then 
   updating clients would overwrite each other's data and flag 
   sections in the control file.
   And that is EXACTLY what Client32's Opportunistic Locking 
   did/does. In order to support Packet Burst, Op Locks were 
   enabled, and the NOS would randomly ignore locking requests, 
   turning the control file into bit soup.
   Recent versions have added a separate setting for Op Locks, but 
   PB doesn't work without em, and it STILL (despite Novell's 
   knowledge of the problem), comes with Op Locks enabled by default.
   It was/is not just ECCO that suffers. I have spoken to at least a 
   dozen folks that were doing things like hitting a remote Access 
   or SQL database over IPX with PB turned on, and it did the same 
   thing to them. Turning Op Locks and PB off solves the problem, 
   but only AFTER significant data loss.
   It's worse than the buggy IDE chip from a few years back.
                                    LRA
 -- SPEED 2.00 #2720: it made a sound like someone was fieldcleaning a badger
--- Platinum Xpress/Win/Wildcat5! v2.0
---------------
* Origin: Memory Alpha - (253) 859-6200 (1:343/311)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.