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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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 f8bebf91abcaa5bda3ec8701f9242f220da8943a)
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 1bbc1ce18b8ccb92b5a78ee648539a591a452118)
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 09dbe8bccec244c8ea0893a7d8ca4fe85d5420f7)
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 3362fcdfa492cfd1d9d4ec35ef2108192302b984)
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)
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 e21aa4cb088f348139309d29c85c48c8b777cff5)
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 2071105b439e87cb1c7c3a8c1b2046441eb46270)
: 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 974af581fe428fd0233c2516b16a5132b0e1b583)
parameter "netbios scope" instead
-i is still available in the command line utils, as these may be used
to contact another scope
(This used to be commit 9fd955409f535850c33af2493d4d2ae493933386)
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 b563be824b8c3141c49558eced7829b48d4ab26f)
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 210d61db08136122f51a93428607fccd582c9e7d)
smbd/dir.c: Reformatting comments.
smbd/ipc.c: New password change code for Win98.
Jeremy.
(This used to be commit 9e90122afd1b6a7cf38660fc3bc3aa8e526bf08b)
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 aa7f81552540f5dca2c146f5edd805611d5b390f)
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 70d6f7635776bba98c9c09405eff6c2087dac590)
part of the data stream. read_data() is a wrapper to guarantee
receiving exactly the requested number of bytes.
(This used to be commit 90c27b7bffa9b2121eaed0e07931830c3ba308d7)
