IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
the last piece was to use a smb timeout slightly larger than the
locking timeout in bloking locks to prevent a race
(This used to be commit 1b54cb4a33)
note the ugly global_smbpid - I hope that won't bethere for long, I
just didn't want to do two lots of major surgery at the one time.
Using global_smbpid avoids the big change of getting rid of our
inbuf/outbuf interface to reply routines. I'll do that once the
locking stuff passes all tests.
(This used to be commit f8bebf91ab)
we now don't pass the lock type at all for unlocks.
I was surprised to discover that NT totally ignores the lock type in
unlocks. It unlocks a matching write lock if there is one, otherwise
it removes the first matching read lock.
(This used to be commit 1bbc1ce18b)
as SMB_OFF_T, we need to do some autoconf changes to generate a 64 bit
int whenever possible (eg. long long on 32 bit i386)
(This used to be commit 09dbe8bcce)
is *missing* from samba cvs main, therefore it is set to all zeros.
this will cause, amongst other things, administrator-changing-user-passwords,
and setting up new accounts, to fail, as the user's password can only be
decoded with the session key (in this case, the administrator's usr sess key).
it's never a perfect world, is it?
(This used to be commit 3362fcdfa4)
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 49637936b6)
After fixing that I needed to use O_RDWR instead of O_WRONLY in
several places to avoid the silly bug in MS servers that doesn't allow
getattrE on a file opened with O_WRONLY
(This used to be commit e21aa4cb08)
of 324 lines (6*6*3*3) of all possible deny mode behaviour. This
allows us to compare with NT. We currently don't match :)
(This used to be commit 2071105b43)
: If a file is resident on NT and the first user opens it read/write with DENY_READ then a subsequent
: attempt by a second user (running under Windows 95) to open it read/write DENY_NONE fails.
: Under samba 2.0.5a the second open succeeds but the file is write only.
Jeremy.
(This used to be commit 974af581fe)
This fixes our netbios scope handling. We now have a 'netbios scope' option
in smb.conf and the scope option is removed from make_nmb_name()
this was prompted by a bug in our PDC finding code where it didn't append
the scope to the query of the '*' name.
(This used to be commit b563be824b)
configure configure.in include/config.h.in: Added <sys/un.h> autoconf
code for Luke's UNIX domain sockets code.
Jeremy.
(This used to be commit 210d61db08)
lp_string() bug properly.
we still need to add lp_talloc_free() calls in all the main event
loops, I've only put it in smbd and nmbd thus far.
(This used to be commit aa7f815525)
size of SMBtrans response, timeout of 10 seconds. read_data() _certainly_
doesn't work, as you don't know what size of the data is going to come
back that needs to be fed back in the SMBtrans response. yes, oops :-)
(This used to be commit 70d6f76357)
