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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If smb_messages flags show for which opcodes VWV(0)
signifies chaining modes, and also which opcodes can
have requests >64K then the bcc / req->in.data_size
fixup in smbsrv_recv_smb_request can be more safely
applied.
This fix permits nttrans requests >64K to be handled.
It is not yet clear if THAT is a good thing, but this
fix does the current thing more nicely.
(This used to be commit 8e4f16e975e192709f398c98650cbe9fe2a76261)
No functional change, just re-ordering so that
smbsrv_recv_smb_request can refer to smb_messages
in a future patch
(This used to be commit d06eafea1a3e7fa61c94492cf504e6fd81da861d)
Erroneous 16bit storage for nttrans counts meant that nttrans behaved
"strangely" for sizes of over 64K
As 32 bit is used in the SMB message and specified in
http://us4.samba.org/samba/ftp/specs/draft-leach-cifs-v1-spec-02.txt
section 3.13.2
this fix changes storage to match.
Signed-off-by: Amin Azez <azez@ufomechanic.net>
(This used to be commit d66b6c3823f003875e3b7cdf63617a894cceadf9)
Note that we don't use any protocol specific values here.
For now only NTVFS_CLIENT_CAP_LEVEL_II_OPLOCKS is defined
others should be defined, when we find out that the ntvfs
layer needs to know about it.
metze
(This used to be commit cc42cd5f6753ca582677fa6f403f0419eec5ab10)
- Updated getinfo structures and field names
- also updated the protocol revision number handling to reflect
new docs
(This used to be commit 3aaa2e86d94675c6c68d66d75292c3e34bfbc81b)
We now define a separate info level RAW_SFILEINFO_RENAME_INFORMATION_SMB2
and set that level when handling SMB2 packets. This makes the parsers clearer.
(This used to be commit f6cdf3f1177f63d80be757f007eb15380839b4f5)
We needed a flag in bufinfo to mark packets as SMB2, as it seems that
SMB2 uses a different format for the RenameInformation buffer than SMB
does
Also handle the fact that SMB2 clients give the full path to the
target file in the rename, not a relative path
(This used to be commit 52d7972d95ddc19d22a4187b4d4428a6c3ed32d5)
This converts our SMB and SMB2 code to use a common structure "struct
request_bufinfo" for information on the buffer bounds of a packet,
alignment information and string handling. This allows us to use a
common backend for SMB and SMB2 code, while still using all the same
string and blob handling functions.
Up to now we had been passing a NULL req handle into these common
routines from the SMB2 side of the server, which meant that we failed
any operation which did a bounds checked string extraction (such as a
RenameInformation setinfo call, which is what Vista uses for renaming
files)
There is still some more work to be done on this - for example we can
now remove many of the SMB2 specific buffer handling functions that we
had, and use the SMB ones.
(This used to be commit ca6d9be6cb6a403a81b18fa6e9a6a0518d7f0f68)
This follows the SMB2 PFIF docs. Current versions of Vista can now connect to Samba4 as a SMB2 server
and do basic operations
(This used to be commit 9dc284770df9393a1a619735dc7a148713936fa7)
fixed the input side of the SMB2 negprot structure and parsers according to the documentation
(This used to be commit 55af8acc7b32c24e4b1187e9d8d1c8f060e914b0)
task_service_init() manually. Now this is called from service.c for
all services.
Andrew Bartlett
(This used to be commit 9c9a4731cafd0dcf6c8523a7b06759cd4f14e4db)
needed to change prefork behaviour based on what service is being
started.
Andrew Bartlett and David Disseldorp
(This used to be commit 0d830580e3539c96da3aa6c72fafe6eacd7a74a0)
req_grow_data was growing the original req, not this_req which
was being used for the current fragment.
(This used to be commit 2ac47f5ab670f971f41f99700dbfb3655fd6737f)
