Stage 1 of PHPTR Edits.

(This used to be commit 64a9e3e8619bf33dcf6b0ff8171b47a3e2581239)

1 files changed, 140 insertions, 136 deletions

diff --git a/docs/Samba3-HOWTO/TOSHARG-locking.xml b/docs/Samba3-HOWTO/TOSHARG-locking.xml
index cb228658e7..4e0c993c56 100644
--- a/docs/Samba3-HOWTO/TOSHARG-locking.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-locking.xml
@@ -30,7 +30,7 @@ a range of functions that are all categorized under this one term.
 <para>
 Opportunistic locking is a desirable feature when it can enhance the
 perceived performance of applications on a networked client. However, the
-opportunistic locking protocol is not robust and, therefore, can
+opportunistic locking protocol is not robust and therefore can
 encounter problems when invoked beyond a simplistic configuration or
 on extended slow or faulty networks. In these cases, operating
 system management of opportunistic locking and/or recovering from
@@ -46,7 +46,7 @@ settings on the MS Windows client.
 
 <note>
 <para>
-Sometimes it is necessary to disable locking control settings on both the Samba
+Sometimes it is necessary to disable locking control settings on the Samba
 server as well as on each MS Windows client!
 </para>
 </note>
@@ -67,7 +67,7 @@ that are specified when a file is open.
 Record locking semantics under UNIX are very different from record locking under
 Windows. Versions of Samba before 2.2 have tried to use the native fcntl() UNIX
 system call to implement proper record locking between different Samba clients.
-This cannot be fully correct for several reasons. The simplest is the fact
+This cannot be fully correct for several reasons. The simplest is
 that a Windows client is allowed to lock a byte range up to 2^32 or 2^64,
 depending on the client OS. The UNIX locking only supports byte ranges up to 2^31.
 So it is not possible to correctly satisfy a lock request above 2^31. There are
@@ -75,16 +75,16 @@ many more differences, too many to be listed here.
 </para>
 
 <para>
-Samba 2.2 and above implements record locking completely independent of the
-underlying UNIX system. If a byte range lock that the client requests happens
-to fall into the range of 0-2^31, Samba hands this request down to the UNIX system.
-All other locks cannot be seen by UNIX, anyway.
+Samba 2.2 and above implement record locking completely independent of the
+underlying UNIX system. If a byte-range lock that the client requests happens
+to fall into the range of 0 to 2^31, Samba hands this request down to the UNIX system.
+No other locks can be seen by UNIX, anyway.
 </para>
 
 <para>
 Strictly speaking, an SMB server should check for locks before every read and write call on
-a file. Unfortunately with the way fcntl() works, this can be slow and may overstress
-the <command>rpc.lockd</command>. This is almost always unnecessary as clients are supposed to
+a file. Unfortunately, with the way fcntl() works, this can be slow and may overstress
+the <command>rpc.lockd</command>. This is almost always unnecessary because clients are supposed to
 independently make locking calls before reads and writes if locking is
 important to them. By default, Samba only makes locking calls when explicitly asked
 to by a client, but if you set <smbconfoption name="strict locking">yes</smbconfoption>, it
@@ -92,10 +92,10 @@ will make lock checking calls on <emphasis>every</emphasis> read and write call.
 </para>
 
 <para>
-You can also disable byte range locking completely by using
+You can also disable byte-range locking completely by using
 <smbconfoption name="locking">no</smbconfoption>.
 This is useful for those shares that do not support locking or do not need it
-(such as CDROMs). In this case, Samba fakes the return codes of locking calls to
+(such as CD-ROMs). In this case, Samba fakes the return codes of locking calls to
 tell clients that everything is okay.
 </para>
 
@@ -112,11 +112,11 @@ modes called <constant>DENY_FCB</constant> and <constant>DENY_DOS</constant>.
 <title>Opportunistic Locking Overview</title>
 
 <para>
-Opportunistic locking (Oplocks) is invoked by the Windows file system
+Opportunistic locking (oplocks) is invoked by the Windows file system
 (as opposed to an API) via registry entries (on the server and the client)
 for the purpose of enhancing network performance when accessing a file
 residing on a server. Performance is enhanced by caching the file
-locally on the client that allows:
+locally on the client that allows the following:
 </para>
 
 <variablelist>
@@ -147,7 +147,7 @@ other processes.
 </para>
 
 <variablelist>
-<title>Windows defines 4 kinds of Oplocks:</title>
+<title>Windows Defines Four Kinds of Oplocks:</title>
 
 	<varlistentry><term>Level1 Oplock</term>
                 <listitem><para>
@@ -161,10 +161,10 @@ other processes.
 
 		<para>
 		If a second process attempts to open the file, the open
-                is deferred while the redirector <quote>breaks</quote> the original
+                is deferred while the redirector "breaks" the original
                 oplock. The oplock break signals the caching client to
                 write the local file back to the server, flush the
-                local locks and discard read-ahead data. The break is
+                local locks, and discard read-ahead data. The break is
                 then complete, the deferred open is granted, and the
                 multiple processes can enjoy concurrent file access as
                 dictated by mandatory or byte-range locking options.
@@ -209,7 +209,7 @@ preparation for the subsequent open by the second process.
 <emphasis>Opportunistic locking</emphasis> is actually an improper name for this feature.
 The true benefit of this feature is client-side data caching, and
 oplocks is merely a notification mechanism for writing data back to the
-networked storage disk. The limitation of opportunistic locking is the
+networked storage disk. The limitation of oplocks is the
 reliability of the mechanism to process an oplock break (notification)
 between the server and the caching client. If this exchange is faulty
 (usually due to timing out for any number of reasons), then the
@@ -221,29 +221,29 @@ The actual decision that a user or administrator should consider is
 whether it is sensible to share among multiple users data that will
 be cached locally on a client. In many cases the answer is no.
 Deciding when to cache or not cache data is the real question, and thus
-<quote>opportunistic locking</quote> should be treated as a toggle for client-side
+oplocks should be treated as a toggle for client-side
 caching. Turn it <quote>on</quote> when client-side caching is desirable and
 reliable. Turn it <quote>off</quote> when client-side caching is redundant,
-unreliable or counter-productive.
+unreliable, or counterproductive.
 </para>
 
 <para>
-Opportunistic locking is by default set to <quote>on</quote> by Samba on all
+Oplocks is by default set to <quote>on</quote> by Samba on all
 configured shares, so careful attention should be given to each case to
 determine if the potential benefit is worth the potential for delays.
 The following recommendations will help to characterize the environment
-where opportunistic locking may be effectively configured.
+where oplocks may be effectively configured.
 </para>
 
 <para>
-Windows opportunistic locking is a lightweight performance-enhancing
+Windows oplocks is a lightweight performance-enhancing
 feature. It is not a robust and reliable protocol. Every
-implementation of opportunistic locking should be evaluated as a
-tradeoff between perceived performance and reliability. Reliability
+implementation of oplocks should be evaluated as a
+trade-off between perceived performance and reliability. Reliability
 decreases as each successive rule above is not enforced. Consider a
-share with oplocks enabled, over a wide area network, to a client on a
+share with oplocks enabled, over a wide-area network, to a client on a
 South Pacific atoll, on a high-availability server, serving a
-mission-critical multi-user corporate database during a tropical
+mission-critical multiuser corporate database during a tropical
 storm. This configuration will likely encounter problems with oplocks.
 </para>
 
@@ -251,43 +251,43 @@ storm. This configuration will likely encounter problems with oplocks.
 Oplocks can be beneficial to perceived client performance when treated
 as a configuration toggle for client-side data caching. If the data
 caching is likely to be interrupted, then oplock usage should be
-reviewed. Samba enables opportunistic locking by default on all
+reviewed. Samba enables oplocks by default on all
 shares. Careful attention should be given to the client usage of
-shared data on the server, the server network reliability and the
-opportunistic locking configuration of each share.
-In mission critical high availability environments, data integrity is
+shared data on the server, the server network reliability, and the
+oplocks configuration of each share.
+In mission-critical, high-availability environments, data integrity is
 often a priority. Complex and expensive configurations are implemented
 to ensure that if a client loses connectivity with a file server, a
-fail-over replacement will be available immediately to provide
+failover replacement will be available immediately to provide
 continuous data availability.
 </para>
 
 <para>
-Windows client fail-over behavior is more at risk of application
+Windows client failover behavior is more at risk of application
 interruption than other platforms because it is dependent upon an
 established TCP transport connection. If the connection is interrupted
-&smbmdash; as in a file server fail-over &smbmdash; a new session must be established.
+&smbmdash; as in a file server failover &smbmdash; a new session must be established.
 It is rare for Windows client applications to be coded to recover
-correctly from a transport connection loss, therefore, most applications
+correctly from a transport connection loss; therefore, most applications
 will experience some sort of interruption &smbmdash; at worst, abort and
 require restarting.
 </para>
 
 <para>
 If a client session has been caching writes and reads locally due to
-opportunistic locking, it is likely that the data will be lost when the
+oplocks, it is likely that the data will be lost when the
 application restarts or recovers from the TCP interrupt. When the TCP
 connection drops, the client state is lost. When the file server
 recovers, an oplock break is not sent to the client. In this case, the
 work from the prior session is lost. Observing this scenario with
 oplocks disabled and with the client writing data to the file server
-real-time,  the fail-over will provide the data on disk as it
+real-time,  the failover will provide the data on disk as it
 existed at the time of the disconnect.
 </para>
 
 <para>
-In mission-critical high-availability environments, careful attention
-should be given to opportunistic locking. Ideally, comprehensive
+In mission-critical, high-availability environments, careful attention
+should be given to oplocks. Ideally, comprehensive
 testing should be done with all affected applications with oplocks
 enabled and disabled.
 </para>
@@ -296,16 +296,16 @@ enabled and disabled.
 <title>Exclusively Accessed Shares</title>
 
 <para>
-Opportunistic locking is most effective when it is confined to shares
+Oplocks is most effective when it is confined to shares
 that are exclusively accessed by a single user, or by only one user at
-a time. Because the true value of opportunistic locking is the local
+a time. Because the true value of oplocks is the local
 client caching of data, any operation that interrupts the caching
 mechanism will cause a delay.
 </para>
 
 <para>
 Home directories are the most obvious examples of where the performance
-benefit of opportunistic locking can be safely realized.
+benefit of oplocks can be safely realized.
 </para>
 
 </sect3>
@@ -314,8 +314,8 @@ benefit of opportunistic locking can be safely realized.
 <title>Multiple-Accessed Shares or Files</title>
 
 <para>
-As each additional user accesses a file in a share with opportunistic
-locking enabled, the potential for delays and resulting perceived poor
+As each additional user accesses a file in a share with oplocks
+enabled, the potential for delays and resulting perceived poor
 performance increases. When multiple users are accessing a file on a
 share that has oplocks enabled, the management impact of sending and
 receiving oplock breaks and the resulting latency while other clients
@@ -344,8 +344,8 @@ exposes the file to likely data corruption.
 </para>
 
 <para>
-If files are shared between Windows clients, and either local UNIX 
-or NFS users, turn opportunistic locking off.
+If files are shared between Windows clients and either local UNIX 
+or NFS users, turn oplocks off.
 </para>
 
 </sect3>
@@ -354,7 +354,7 @@ or NFS users, turn opportunistic locking off.
 <title>Slow and/or Unreliable Networks</title>
 
 <para>
-The biggest potential performance improvement for opportunistic locking
+The biggest potential performance improvement for oplocks
 occurs when the client-side caching of reads and writes delivers the
 most differential over sending those reads and writes over the wire.
 This is most likely to occur when the network is extremely slow,
@@ -363,28 +363,28 @@ has a high impact on the reliability of the oplock break
 mechanism, and thus increases the likelihood of encountering oplock
 problems that more than offset the potential perceived performance
 gain. Of course, if an oplock break never has to be sent, then this is
-the most advantageous scenario to utilize opportunistic locking.
+the most advantageous scenario in which to utilize oplocks.
 </para>
 
 <para>
 If the network is slow, unreliable, or a WAN, then do not configure
-opportunistic locking if there is any chance of multiple users
+oplocks if there is any chance of multiple users
 regularly opening the same file.
 </para>
 
 </sect3>
 
 <sect3>
-<title>Multi-User Databases</title>
+<title>Multiuser Databases</title>
 
 <para>
-Multi-user databases clearly pose a risk due to their very nature &smbmdash;
+Multiuser databases clearly pose a risk due to their very nature &smbmdash;
 they are typically heavily accessed by numerous users at random
-intervals. Placing a multi-user database on a share with opportunistic
-locking enabled will likely result in a locking management bottleneck
+intervals. Placing a multi-user database on a share with oplocks
+enabled will likely result in a locking management bottleneck
 on the Samba server. Whether the database application is developed
 in-house or a commercially available product, ensure that the share
-has opportunistic locking disabled.
+has oplocks disabled.
 </para>
 
 </sect3>
@@ -393,17 +393,17 @@ has opportunistic locking disabled.
 <title>PDM Data Shares</title>
 
 <para>
-Process Data Management (PDM) applications such as IMAN, Enovia and
-Clearcase are increasing in usage with Windows client platforms, and
-therefore SMB data-stores. PDM applications manage multi-user
+Process data management (PDM) applications such as IMAN, Enovia, and
+Clearcase are increasing in usage with Windows client platforms and
+therefore with SMB datastores. PDM applications manage multiuser
 environments for critical data security and access. The typical PDM
 environment is usually associated with sophisticated client design
 applications that will load data locally as demanded. In addition, the
-PDM application will usually monitor the data-state of each client.
+PDM application will usually monitor the data state of each client.
 In this case, client-side data caching is best left to the local
 application and PDM server to negotiate and maintain. It is
 appropriate to eliminate the client OS from any caching tasks, and the
-server from any oplock management, by disabling opportunistic locking on
+server from any oplocks management, by disabling oplocks on
 the share.
 </para>
 
@@ -416,7 +416,7 @@ the share.
 Samba includes an &smb.conf; parameter called 
 <smbconfoption name="force user"/> that changes
 the user accessing a share from the incoming user to whatever user is
-defined by the smb.conf variable. If opportunistic locking is enabled
+defined by the smb.conf variable. If oplocks is enabled
 on a share, the change in user access causes an oplock break to be sent
 to the client, even if the user has not explicitly loaded a file. In
 cases where the network is slow or unreliable, an oplock break can
@@ -435,31 +435,31 @@ Avoid the combination of the following:
 	</para></listitem>
 
 	<listitem><para>
-	Slow or unreliable networks
+	Slow or unreliable networks.
 	</para></listitem>
 
 	<listitem><para>
-	Opportunistic locking enabled
+	Oplocks enabled.
 	</para></listitem>
 </itemizedlist>
 
 </sect3>
 
 <sect3>
-<title>Advanced Samba Opportunistic Locking Parameters</title>
+<title>Advanced Samba Oplocks Parameters</title>
 
 <para>
-Samba provides opportunistic locking parameters that allow the
+Samba provides oplocks parameters that allow the
 administrator to adjust various properties of the oplock mechanism to
 account for timing and usage levels. These parameters provide good
 versatility for implementing oplocks in environments where they would
-likely cause problems. The parameters are: 
-<smbconfoption name="oplock break wait time"/>,
+likely cause problems. The parameters are 
+<smbconfoption name="oplock break wait time"/>, and
 <smbconfoption name="oplock contention limit"/>.
 </para>
 
 <para>
-For most users, administrators and environments, if these parameters
+For most users, administrators, and environments, if these parameters
 are required, then the better option is to simply turn oplocks off.
 The Samba SWAT help text for both parameters reads: <quote>Do not change
 this parameter unless you have read and understood the Samba oplock code.</quote>
@@ -469,43 +469,43 @@ This is good advice.
 </sect3>
 
 <sect3>
-<title>Mission-Critical High-Availability</title>
+<title>Mission-Critical, High-Availability</title>
 
 <para>
-In mission-critical high-availability environments, data integrity is
+In mission-critical, high-availability environments, data integrity is
 often a priority. Complex and expensive configurations are implemented
 to ensure that if a client loses connectivity with a file server, a
-fail-over replacement will be available immediately to provide
+failover replacement will be available immediately to provide
 continuous data availability.
 </para>
 
 <para>
-Windows client fail-over behavior is more at risk of application
-interruption than other platforms because it is dependant upon an
+Windows client failover behavior is more at risk of application
+interruption than other platforms because it is dependent upon an
 established TCP transport connection. If the connection is interrupted
-&smbmdash; as in a file server fail-over &smbmdash; a new session must be established.
+&smbmdash; as in a file server failover &smbmdash; a new session must be established.
 It is rare for Windows client applications to be coded to recover
-correctly from a transport connection loss, therefore, most applications
+correctly from a transport connection loss; therefore, most applications
 will experience some sort of interruption &smbmdash; at worst, abort and
 require restarting.
 </para>
 
 <para>
 If a client session has been caching writes and reads locally due to
-opportunistic locking, it is likely that the data will be lost when the
-application restarts, or recovers from the TCP interrupt. When the TCP
+oplocks, it is likely that the data will be lost when the
+application restarts or recovers from the TCP interrupt. When the TCP
 connection drops, the client state is lost. When the file server
 recovers, an oplock break is not sent to the client. In this case, the
 work from the prior session is lost. Observing this scenario with
-oplocks disabled, and the client was writing data to the file server
-real-time, then the fail-over will provide the data on disk as it
+oplocks disabled, if the client was writing data to the file server
+real-time, then the failover will provide the data on disk as it
 existed at the time of the disconnect.
 </para>
 
 <para>
-In mission-critical high-availability environments, careful attention
-should be given to opportunistic locking. Ideally, comprehensive
-testing should be done with all effected applications with oplocks
+In mission-critical, high-availability environments, careful attention
+should be given to oplocks. Ideally, comprehensive
+testing should be done with all affected applications with oplocks
 enabled and disabled.
 </para>
 
@@ -514,30 +514,30 @@ enabled and disabled.
 </sect1>
 
 <sect1>
-<title>Samba Opportunistic Locking Control</title>
+<title>Samba Oplocks Control</title>
 
 <para>
-Opportunistic locking is a unique Windows file locking feature. It is
+Oplocks is a unique Windows file locking feature. It is
 not really file locking, but is included in most discussions of Windows
 file locking, so is considered a de facto locking feature.
-Opportunistic locking is actually part of the Windows client file
+Oplocks is actually part of the Windows client file
 caching mechanism. It is not a particularly robust or reliable feature
 when implemented on the variety of customized networks that exist in
 enterprise computing.
 </para>
 
 <para>
-Like Windows, Samba implements opportunistic locking as a server-side
+Like Windows, Samba implements oplocks as a server-side
 component of the client caching mechanism. Because of the lightweight
 nature of the Windows feature design, effective configuration of
-opportunistic locking requires a good understanding of its limitations,
+oplocks requires a good understanding of its limitations,
 and then applying that understanding when configuring data access for
 each particular customized network and client usage state.
 </para>
 
 <para>
-Opportunistic locking essentially means that the client is allowed to download and cache
-a file on their hard drive while making changes; if a second client wants to access the
+Oplocks essentially means that the client is allowed to download and cache
+a file on its hard drive while making changes; if a second client wants to access the
 file, the first client receives a break and must synchronize the file back to the server.
 This can give significant performance gains in some cases; some programs insist on
 synchronizing the contents of the entire file back to the server for a single change.
@@ -556,7 +556,7 @@ on files that the client has no initial intention to write to at time of opening
 <para>
 Kernel Oplocks are essentially a method that allows the Linux kernel to co-exist with
 Samba's oplocked files, although this has provided better integration of MS Windows network
-file locking with the underlying OS, SGI IRIX and Linux are the only two OSs that are
+file locking with the underlying OS. SGI IRIX and Linux are the only two OSs that are
 oplock-aware at this time.
 </para>
 
@@ -564,7 +564,7 @@ oplock-aware at this time.
 Unless your system supports kernel oplocks, you should disable oplocks if you are
 accessing the same files from both UNIX/Linux and SMB clients. Regardless, oplocks should
 always be disabled if you are sharing a database file (e.g., Microsoft Access) between
-multiple clients, as any break the first client receives will affect synchronization of
+multiple clients, because any break the first client receives will affect synchronization of
 the entire file (not just the single record), which will result in a noticeable performance
 impairment and, more likely, problems accessing the database in the first place. Notably,
 Microsoft Outlook's personal folders (*.pst) react quite badly to oplocks. If in doubt,
@@ -622,7 +622,7 @@ Alternately, you could disable oplocks on a per-file basis within the share:
 </para>
 
 <para>
-If you are experiencing problems with oplocks as apparent from Samba's log entries,
+If you are experiencing problems with oplocks, as apparent from Samba's log entries,
 you may want to play it safe and disable oplocks and Level2 oplocks.
 </para>
 
@@ -653,21 +653,22 @@ The default is no.
 </para>
 
 <para>
-Veto opLocks is an &smb.conf; parameter that identifies specific files for
+<emphasis>Veto oplocks</emphasis> is an &smb.conf; parameter that identifies specific files for
 which oplocks are disabled. When a Windows client opens a file that
 has been configured for veto oplocks, the client will not be granted
 the oplock, and all operations will be executed on the original file on
 disk instead of a client-cached file copy. By explicitly identifying
 files that are shared with UNIX processes and disabling oplocks for
-those files, the server-wide Oplock configuration can be enabled to
+those files, the server-wide oplock configuration can be enabled to
 allow Windows clients to utilize the performance benefit of file
-caching without the risk of data corruption. Veto Oplocks can be
+caching without the risk of data corruption. Veto oplocks can be
 enabled on a per-share basis, or globally for the entire server, in the
 &smb.conf; file as shown in <link linkend="far1"/>.
 </para>
 
+<para>
 <example id="far1">
-<title>Share with some files oplocked</title>
+<title>Share with Some Files Oplocked</title>
 <smbconfblock>
 <smbconfsection name="[global]"/>
 <smbconfoption name="veto oplock files">/filename.htm/*.txt/</smbconfoption>
@@ -676,12 +677,13 @@ enabled on a per-share basis, or globally for the entire server, in the
 <smbconfoption name="veto oplock files">/*.exe/filename.ext/</smbconfoption>
 </smbconfblock>
 </example>
+</para>
 
 <para>
 <smbconfoption name="oplock break wait time"/> is an &smb.conf; parameter
 that adjusts the time interval for Samba to reply to an oplock break request. Samba recommends:
 <quote>Do not change this parameter unless you have read and understood the Samba oplock code.</quote>
-Oplock break Wait Time can only be configured globally in the &smb.conf; file as shown below.
+Oplock break wait time can only be configured globally in the &smb.conf; file as shown:
 </para>
 
 <para>
@@ -695,13 +697,14 @@ Oplock break Wait Time can only be configured globally in the &smb.conf; file as
 response of the Samba server to grant an oplock if the configured
 number of contending clients reaches the limit specified by the parameter. Samba recommends
 <quote>Do not change this parameter unless you have read and understood the Samba oplock code.</quote>
-Oplock break Contention Limit can be enable on a per-share basis, or globally for
+Oplock break contention limit can be enabled on a per-share basis, or globally for
 the entire server, in the &smb.conf; file as shown in <link linkend="far3"/>.
 </para>
 
+<para>
 <example id="far3">
-	<title>Configuration with oplock break contention limit</title>
-	<smbconfblock>
+<title>Configuration with Oplock Break Contention Limit</title>
+<smbconfblock>
 <smbconfsection name="[global]"/>
 <smbconfoption name="oplock break contention limit"> 2 (default)</smbconfoption>
 
@@ -709,6 +712,7 @@ the entire server, in the &smb.conf; file as shown in <link linkend="far3"/>.
 <smbconfoption name="oplock break contention limit"> 2 (default)</smbconfoption>
 </smbconfblock>
 </example>
+</para>
 
 </sect3>
 </sect2>
@@ -716,13 +720,13 @@ the entire server, in the &smb.conf; file as shown in <link linkend="far3"/>.
 </sect1>
 
 <sect1>
-<title>MS Windows Opportunistic Locking and Caching Controls</title>
+<title>MS Windows Oplocks and Caching Controls</title>
 
 <para>
-There is a known issue when running applications (like Norton Anti-Virus) on a Windows 2000/ XP
+There is a known issue when running applications (like Norton Antivirus) on a Windows 2000/ XP
 workstation computer that can affect any application attempting to access shared database files
 across a network. This is a result of a default setting configured in the Windows 2000/XP
-operating system known as <emphasis>opportunistic locking</emphasis>. When a workstation
+operating system. When a workstation
 attempts to access shared data files located on another Windows 2000/XP computer,
 the Windows 2000/XP operating system will attempt to increase performance by locking the
 files and caching information locally. When this occurs, the application is unable to
@@ -733,14 +737,14 @@ properly function, which results in an <quote>Access Denied</quote>
 <para>
 All Windows operating systems in the NT family that act as database servers for data files
 (meaning that data files are stored there and accessed by other Windows PCs) may need to
-have opportunistic locking disabled in order to minimize the risk of data file corruption.
+have oplocks disabled in order to minimize the risk of data file corruption.
 This includes Windows 9x/Me, Windows NT, Windows 200x, and Windows XP.
 <footnote><para>Microsoft has documented this in Knowledge Base article 300216.</para></footnote>
 </para>
 
 <para>
 If you are using a Windows NT family workstation in place of a server, you must also
-disable opportunistic locking (oplocks) on that workstation. For example, if you use a
+disable oplocks on that workstation. For example, if you use a
 PC with the Windows NT Workstation operating system instead of Windows NT Server, and you
 have data files located on it that are accessed from other Windows PCs, you may need to
 disable oplocks on that system.
@@ -759,7 +763,7 @@ to ensure that the new setting goes into effect.
 </para>
 
 <para>
-The location of the client registry entry for opportunistic locking has changed in
+The location of the client registry entry for oplocks has changed in
 Windows 2000 from the earlier location in Microsoft Windows NT.
 </para>
 
@@ -769,7 +773,7 @@ in earlier versions of Windows.
 </para></note>
 
 <para>
-You can also deny the granting of opportunistic locks by changing the following registry entries:
+You can also deny the granting of oplocks by changing the following registry entries:
 </para>
 
 <para>
@@ -784,7 +788,7 @@ You can also deny the granting of opportunistic locks by changing the following
 
 <note><para>
 The OplocksDisabled registry value configures Windows clients to either request or not
-request opportunistic locks on a remote file. To disable oplocks, the value of
+request oplocks on a remote file. To disable oplocks, the value of
  OplocksDisabled must be set to 1.
 </para></note>
 
@@ -803,7 +807,7 @@ request opportunistic locks on a remote file. To disable oplocks, the value of
 
 <note><para>
 The EnableOplocks value configures Windows-based servers (including Workstations sharing
-files) to allow or deny opportunistic locks on local files.
+files) to allow or deny oplocks on local files.
 </para></note>
 
 <para>
@@ -811,7 +815,7 @@ To force closure of open oplocks on close or program exit, EnableOpLockForceClos
 </para>
 
 <para>
-An illustration of how Level2 oplocks work:
+An illustration of how Level2 oplocks work follows:
 </para>
 
 <itemizedlist>
@@ -832,7 +836,7 @@ An illustration of how Level2 oplocks work:
 	Station 1 complies by flushing locally buffered lock information to the server.
 	</para></listitem>
 	<listitem><para>
-	Station 1 informs the server that it has Broken to Level2 Oplock (alternately,
+	Station 1 informs the server that it has broken to level2 Oplock (alternately,
 	station 1 could have closed the file).
 	</para></listitem>
 	<listitem><para>
@@ -863,7 +867,7 @@ An illustration of how Level2 oplocks work:
 </programlisting></para>
 
 <para>
-This indicates whether the redirector should use opportunistic-locking (oplock) performance
+This indicates whether the redirector should use oplocks performance
 enhancement. This parameter should be disabled only to isolate problems.
 </para>
 
@@ -882,7 +886,7 @@ enhancement. This parameter should be disabled only to isolate problems.
 <para>
 This specifies whether the server allows clients to use oplocks on files. Oplocks are a
 significant performance enhancement, but have the potential to cause lost cached
-data on some networks, particularly wide area networks.
+data on some networks, particularly WANs.
 </para>
 
 <para><programlisting>
@@ -892,7 +896,7 @@ data on some networks, particularly wide area networks.
 
 <para>
 This specifies the minimum link throughput allowed by the server before it disables
-raw and opportunistic locks for this connection.
+raw I/O and oplocks for this connection.
 </para>
 
 <para><programlisting>
@@ -902,7 +906,7 @@ raw and opportunistic locks for this connection.
 
 <para>
 This specifies the maximum time allowed for a link delay. If delays exceed this number,
-the server disables raw I/O and opportunistic locking for this connection.
+the server disables raw I/O and oplocks for this connection.
 </para>
 
 <para><programlisting>
@@ -934,7 +938,7 @@ If you see persistent data corruption even after repeated re-indexing, you may h
 rebuild the data files in question. This involves creating a new data file with the
 same definition as the file to be rebuilt and transferring the data from the old file
 to the new one. There are several known methods for doing this that can be found in
-our Knowledge Base.
+our knowledge base.
 </para>
 
 </sect1>
@@ -943,9 +947,9 @@ our Knowledge Base.
 <title>Common Errors</title>
 
 <para>
-In some sites, locking problems surface as soon as a server is installed; in other sites
+In some sites locking problems surface as soon as a server is installed; in other sites
 locking problems may not surface for a long time. Almost without exception, when a locking
-problem does surface it will cause embarrassment and potential data corruption.
+problem does surface, it will cause embarrassment and potential data corruption.
 </para>
 
 <para>
@@ -956,8 +960,8 @@ so far:
 
 <itemizedlist>
 	<listitem><para>
-	Incorrect configuration of opportunistic locking (incompatible with the application
-	being used. This is a common problem even where MS Windows NT4 or MS Windows
+	Incorrect configuration of oplocks (incompatible with the application
+	being used). This is a common problem even where MS Windows NT4 or MS Windows
 	200x-based servers were in use. It is imperative that the software application vendors'
 	instructions for configuration of file locking should be followed. If in doubt,
 	disable oplocks on both the server and the client. Disabling of all forms of file
@@ -965,21 +969,21 @@ so far:
 	</para></listitem>
 
 	<listitem><para>
-	Defective network cards, cables, or HUBs/Switched. This is generally a more
-	prevalent factor with low cost networking hardware, although occasionally there
+	Defective network cards, cables, or hubs/switches. This is generally a more
+	prevalent factor with low-cost networking hardware, although occasionally there
 	have also been problems with incompatibilities in more up-market hardware.
 	</para></listitem>
 
 	<listitem><para>
 	There have been some random reports of Samba log files being written over data
-	files. This has been reported by very few sites (about five in the past three years)
+	files. This has been reported by very few sites (about five in the past 3 years)
 	and all attempts to reproduce the problem have failed. The Samba Team has been
-	unable to catch this happening and thus has not been able to isolate any particular
+	unable to catch this happening and thus unable to isolate any particular
 	cause. Considering the millions of systems that use Samba, for the sites that have
-	been affected by this as well as for the Samba Team this is a frustrating and
-	a vexing challenge. If you see this type of thing happening, please create a bug
+	been affected by this as well as for the Samba Team, this is a frustrating and
+	vexing challenge. If you see this type of thing happening, please create a bug
 	report on Samba <ulink url="https://bugzilla.samba.org">Bugzilla</ulink> without delay.
-	Make sure that you give as much information as you possibly can help isolate the
+	Make sure that you give as much information as you possibly can to help isolate the
 	cause and to allow replication of the problem (an essential step in problem isolation and correction).
 	</para></listitem>
 </itemizedlist>
@@ -1002,7 +1006,7 @@ tdb(/usr/local/samba_2.2.7/var/locks/locking.tdb): rec_read bad magic
 	</para>
 
 	<para>
-	This error indicated a corrupted tdb. Stop all instances of smbd, delete locking.tdb, and restart smbd.
+	This error indicates a corrupted tdb. Stop all instances of smbd, delete locking.tdb, and restart smbd.
 	</para>
 
 	</sect2>
@@ -1011,18 +1015,18 @@ tdb(/usr/local/samba_2.2.7/var/locks/locking.tdb): rec_read bad magic
 		<title>Problems Saving Files in MS Office on Windows XP</title>
 
 		<para>This is a bug in Windows XP. More information can be 
-		found in <ulink url="http://support.microsoft.com/?id=812937">Microsoft Knowledge Base article 812937.</ulink></para>
+		found in <ulink url="http://support.microsoft.com/?id=812937">Microsoft Knowledge Base article 812937</ulink></para>.
 
 	</sect2>
 
 	<sect2>
 
-		<title>Long Delays Deleting Files Over Network with XP SP1</title>
+		<title>Long Delays Deleting Files over Network with XP SP1</title>
 		
 		<para><quote>It sometimes takes approximately 35 seconds to delete files over the network after XP SP1 has been applied.</quote></para>
 
 		<para>This is a bug in Windows XP. More information can be found in <ulink url="http://support.microsoft.com/?id=811492">
-				Microsoft Knowledge Base article 811492.</ulink></para>
+				Microsoft Knowledge Base article 811492</ulink></para>.
 	</sect2>
 
 </sect1>
@@ -1043,24 +1047,24 @@ Section of the Microsoft MSDN Library on opportunistic locking:
 <para>
 Opportunistic Locks, Microsoft Developer Network (MSDN), Windows Development &gt;
 Windows Base Services &gt; Files and I/O &gt; SDK Documentation &gt; File Storage &gt; File Systems
-&gt; About File Systems &gt; Opportunistic Locks, Microsoft Corporation.
-<ulink noescape="1" url="http://msdn.microsoft.com/library/en-us/fileio/storage_5yk3.asp">http://msdn.microsoft.com/library/en-us/fileio/storage_5yk3.asp</ulink>
+&gt; About File Systems &gt; Opportunistic Locks, Microsoft Corporation
+<ulink noescape="1" url="http://msdn.microsoft.com/library/en-us/fileio/storage_5yk3.asp">http://msdn.microsoft.com/library/en-us/fileio/storage_5yk3.asp</ulink>.
 </para>
 
 <para>
-	Microsoft Knowledge Base Article Q224992 <?latex \linebreak ?><quote>Maintaining Transactional Integrity 
+	Microsoft Knowledge Base Article Q224992, <?latex \linebreak ?><quote>Maintaining Transactional Integrity 
 with OPLOCKS</quote>,
 Microsoft Corporation, April 1999, <ulink noescape="1" url="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224992">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224992</ulink>.
 </para>
 
 <para>
-Microsoft Knowledge Base Article Q296264 <quote>Configuring Opportunistic Locking in Windows 2000</quote>,
-Microsoft Corporation, April 2001, <ulink noescape="1" url="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264</ulink>.
+Microsoft Knowledge Base Article Q296264, <quote>Configuring Opportunistic Locking in Windows 2000</quote>,
+Microsoft Corporation, April 2001 <ulink noescape="1" url="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264</ulink>.
 </para>
 
 <para>
-Microsoft Knowledge Base Article Q129202 <quote>PC Ext: Explanation of Opportunistic Locking on Windows NT</quote>,
-Microsoft Corporation, April 1995, <ulink noescape="1" url="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q129202">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q129202</ulink>.
+Microsoft Knowledge Base Article Q129202, <quote>PC Ext: Explanation of Opportunistic Locking on Windows NT</quote>,
+Microsoft Corporation, April 1995 <ulink noescape="1" url="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q129202">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q129202</ulink>.
 </para>
 
 </sect1>