summaryrefslogtreecommitdiff
path: root/source3/libsmb/clientgen.c
diff options
context:
space:
mode:
authorAndrew Tridgell <tridge@samba.org>2000-01-10 14:41:20 +0000
committerAndrew Tridgell <tridge@samba.org>2000-01-10 14:41:20 +0000
commit0af00edf672eda7556f12745c80873376b85676f (patch)
tree96bdd16f282ccca726a0c739de2585f705032e4f /source3/libsmb/clientgen.c
parent735ee07018f4514771d26e01b41b0f02295b8b48 (diff)
downloadsamba-0af00edf672eda7556f12745c80873376b85676f.tar.gz
samba-0af00edf672eda7556f12745c80873376b85676f.tar.bz2
samba-0af00edf672eda7556f12745c80873376b85676f.zip
I'm currently designing a new locking system (using a tdb database!)
that will make us match NT semantics exactly and do away with the horrible fd multiplexing in smbd. this is some diag stuff to get me started. - added the ability to do read or write locks in clientgen.c - added a LOCK4 test to smbtorture. This produces a report on the server and its locking capabilities. For example, NT4 gives this: the same process cannot set overlapping write locks the same process can set overlapping read locks a different connection cannot set overlapping write locks a different connection can set overlapping read locks a different pid cannot set overlapping write locks a different pid can set overlapping read locks the same process can set the same read lock twice the same process cannot set the same write lock twice the same process cannot override a read lock with a write lock the same process can override a write lock with a read lock a different pid cannot override a write lock with a read lock the same process cannot coalesce read locks this server does strict write locking this server does strict read locking whereas Samba currently gives this: the same process can set overlapping write locks the same process can set overlapping read locks a different connection cannot set overlapping write locks a different connection can set overlapping read locks a different pid can set overlapping write locks a different pid can set overlapping read locks the same process can set the same read lock twice the same process can set the same write lock twice the same process can override a read lock with a write lock the same process can override a write lock with a read lock a different pid can override a write lock with a read lock the same process can coalesce read locks this server does strict write locking this server does strict read locking win95 gives this - I don't understand why! the same process cannot set overlapping write locks the same process cannot set overlapping read locks a different connection cannot set overlapping write locks a different connection cannot set overlapping read locks a different pid cannot set overlapping write locks a different pid cannot set overlapping read locks the same process cannot set the same read lock twice the same process cannot set the same write lock twice the same process cannot override a read lock with a write lock the same process cannot override a write lock with a read lock a different pid cannot override a write lock with a read lock the same process cannot coalesce read locks this server does strict write locking this server does strict read locking (This used to be commit 49637936b6e9478df248c4ef73d818870c73b597)
Diffstat (limited to 'source3/libsmb/clientgen.c')
-rw-r--r--source3/libsmb/clientgen.c10
1 files changed, 6 insertions, 4 deletions
diff --git a/source3/libsmb/clientgen.c b/source3/libsmb/clientgen.c
index 3b6403fe73..bf610a7ff7 100644
--- a/source3/libsmb/clientgen.c
+++ b/source3/libsmb/clientgen.c
@@ -1344,7 +1344,8 @@ BOOL cli_close(struct cli_state *cli, int fnum)
/****************************************************************************
lock a file
****************************************************************************/
-BOOL cli_lock(struct cli_state *cli, int fnum, uint32 offset, uint32 len, int timeout)
+BOOL cli_lock(struct cli_state *cli, int fnum,
+ uint32 offset, uint32 len, int timeout, int locktype)
{
char *p;
int saved_timeout = cli->timeout;
@@ -1360,7 +1361,7 @@ BOOL cli_lock(struct cli_state *cli, int fnum, uint32 offset, uint32 len, int ti
CVAL(cli->outbuf,smb_vwv0) = 0xFF;
SSVAL(cli->outbuf,smb_vwv2,fnum);
- CVAL(cli->outbuf,smb_vwv3) = 0;
+ CVAL(cli->outbuf,smb_vwv3) = (locktype == F_RDLCK? 1 : 0);
SIVALS(cli->outbuf, smb_vwv4, timeout);
SSVAL(cli->outbuf,smb_vwv6,0);
SSVAL(cli->outbuf,smb_vwv7,1);
@@ -1390,7 +1391,8 @@ BOOL cli_lock(struct cli_state *cli, int fnum, uint32 offset, uint32 len, int ti
/****************************************************************************
unlock a file
****************************************************************************/
-BOOL cli_unlock(struct cli_state *cli, int fnum, uint32 offset, uint32 len, int timeout)
+BOOL cli_unlock(struct cli_state *cli, int fnum,
+ uint32 offset, uint32 len, int timeout, int locktype)
{
char *p;
@@ -1405,7 +1407,7 @@ BOOL cli_unlock(struct cli_state *cli, int fnum, uint32 offset, uint32 len, int
CVAL(cli->outbuf,smb_vwv0) = 0xFF;
SSVAL(cli->outbuf,smb_vwv2,fnum);
- CVAL(cli->outbuf,smb_vwv3) = 0;
+ CVAL(cli->outbuf,smb_vwv3) = (locktype == F_RDLCK? 1 : 0);
SIVALS(cli->outbuf, smb_vwv4, timeout);
SSVAL(cli->outbuf,smb_vwv6,1);
SSVAL(cli->outbuf,smb_vwv7,0);