Re: Re: file locking

of note, locks may be placed beyond the current end-of-file offset.  thus,

        if (LargeIntegerLessThan(LOffset, scp->length))
            continue;

is incorrect.  since this code is currently in place, there may be a
temptation to leave it unaltered.  however, locks that start (or extend)
beyond the end of the file are used for synchronization.

i know this is the case for IFS-received requests; SMB-encapsulated
requests should not be different.

eric


On Fri, 22 Jul 2005, Jeffrey Altman wrote:

> It appears that the problems with byte-range locks in the existing
> SMB/CIFS client are two-fold:
>
> (1) the ReceiveV3LockingX function intentionlly ignores any request
>     for a lock whose offset does not equal zero and whose length is
>     not the size of the file
>
> (2) the cm_scache_t object contains a lock queue but the cm_Lock
>     function does nothing to attempt to manage lock ranges.  Any
>     lock that exists will result in subsequent non-overlapping locks
>     failing with a CM_ERROR_WOULDBLOCK error.
>
> It seems clear to me that cm_Lock and cm_Unlock need to be fixed both
> for the use of the SMB/CIFS client but also if the IFS client wants to
> be able to use them.
>
> Jeffrey Altman
>
>
>