IFSMgr_LockFile( void ** ppFSDLockListHead, unsigned long LockOffset, unsigned long LockLength, unsigned long LockOwner, void * pOpenFileInstance, unsigned long fLockSemantics )
This service locks a region of an open file. This service supports two kinds of locking semantics: DOS and Netware. DOS semantics do not allow overlapping locks and a lock prevents any access to that region of the file by another process. On the other hand, Netware's locking semantics provides for overlapping read locks and non-overlapping write locks. It also has the concept of lock promotion of a read lock to a write lock and vice versa. For more details on the Netware locking semantics, please refer to the appropriate Netware documentation.
ppFSDLockListHead
Supplies a pointer to a variable that is to contain the pointer to the list of locks.
LockOffset
Supplies the starting offset in the file of the region to be locked.
LockLength
Supplies the length of region in the file to be locked.
LockOwner
Supplies the process id of the process requesting the lock.
pOpenFileInstance
Supplies a pointer to the structure that describes the current open file instance.
fLockSemantics
Supplies flags indicating what kind of locking semantics are operative.
Lock Semantics Flags: | |
Value | Meaning |
LOCKF_DOS | Indicates that DOS semantics are to be applied for the lock request. |
LOCKF_NW | Indicate that Netware semantics are to be applied for the lock request. |
LOCKF_RD | Indicates that a read lock should be taken. This value is allowed only with LOCKF_NW. DOS semantics do not have the concept of a read lock. |
LOCKF_WR | Indicates that a write lock should be taken. |
ppFSDLockListHead | The pointer to the lock list is stored in this variable on a successful return. |
The IFS manager maintains a list of active locks on the file. The head of this list is stored in the variable pointed to by ppFSDLockListHead. The FSD should not attempt to interpret this list in any fashion, it is only for use by the IFS manager. Typically, the head for the list of locks would be a part of the open file information structure and would be maintained on a per-open-file basis. All locks on this open file are part of this list, irrespective of which process and which open file instance they belong to.