Cross-Protocol locks help prevent the same file from being concurrently accessed for modifications. This option ensures that a file is updated correctly before another user, application, or process can access it.
Byte-Range Locking: Two types of byte-range locking are used:
Exclusive Lock: The locked byte range is read/write for the holder of the lock and deny-all for all others. A write lock on a byte range is acquired by an application that intends to write data into that byte range, and does not want other applications to be able to read or write to the byte range while it is accessing that byte range. A write lock on a given byte range is exclusive. It is granted to only one requester at a time. A write lock denies other applications the ability to either read or write to the locked byte-range.
Shared Lock: Also called a non-exclusive byte-range lock. The locked byte range is read-only for the holder of the lock and deny-write for all others. A read lock on a byte range is normally acquired by an application that intends to read data from the byte range, and does not want other applications to be able to write to the byte range while it is performing the read operation. A read lock on a given byte range is sharable, which means it is granted to multiple requesters concurrently. However, it is incompatible with a concurrent write lock on the same byte range. A read lock denies other applications the ability to write to the locked byte range. In environments that implement advisory record locking rather than mandatory record locking, a read lock simply advises other applications that they should not write to the locked byte-range, even though they are technically able to do so.
Opportunistic Locking: Opportunistic Locking or Oplocks improves file access performance and is enabled by default. Oplocks must be enabled on the server for Offline files to function correctly on Windows XP, Windows Vista, and Windows 7.
IMPORTANT:.If a file is opened with multiple protocols when the migration or failover begins, the file should be closed and reopened after the migration or failover to acquire cross-protocol locks on the new node.
For more information, see OES 2 SP3: NCP Server for Linux Administration Guide.