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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In future this will an impersonation wrapper tevent_context based on the
user session.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
This improves profiling and corrently counts the total and idle time for async
requests.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We need to use the connection that is used by the current request.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
We don't need this twice...
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
This is a hack, but it should fix the bug:
change_notify_add_request() talloc moves smb_request away,
which is not expected by the smb2_notify.c code...
smbd_smb2_notify_reply() uses tevent_req_defer_callback()
(in older versions an immediate event) to defer the response.
This is needed as change_notify_reply() will do more things
after calling reply_fn() (smbd_smb2_notify_reply is this case)
and often change_notify_remove_request() is called after
change_notify_reply().
change_notify_remove_request() implicitly free's the smb_request
that was passed to change_notify_add_request().
smbd_smb2_fake_smb_request() added the smb_request as smb2req->smb1req,
which is expected to be available after smbd_smb2_notify_recv() returned.
The long term solution would be the following interface:
struct tevent_req *change_notify_request_send(TALLOC_CTX *mem_ctx,
struct tevent_context *ev,
struct files_struct *fsp,
uint32_t max_length,
uint32_t filter,
bool recursive);
NTSTATUS change_notify_request_recv(struct tevent_req *req,
TALLOC_CTX *mem_ctx,
DATA_BLOB *buffer);
Bug: https://bugzilla.samba.org/show_bug.cgi?id=10442
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Fri Feb 14 11:18:15 CET 2014 on sn-devel-104
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Wed Dec 4 20:09:39 CET 2013 on sn-devel-104
for all requests that have max_???? checks, also do a check of the
creditcharge the client has sent (when using largemtu)
Signed-off-by: Jeremy Allison <jra@samba.org>
It turns out that the persistent handles are used by the Microsoft
redirector to index files on oplock break requests. So even if we
don't do durable handles (yet) we must set the persistent handle
on create. For now just use the same handle value as we use for
volatile.
Jeremy.
Don't free the cancelled SMB2 req early, let the cancelation
function take care of it. Return a NT_STATUS_CANCELLED when
we find and cancel a request. Fix our SMB2 error returns to
correctly set the structuresize to 9, and add the expected
zero byte (see section 2.2.2 in the SMB2 spec.).
This causes Samba to pass the test program in this bug report
that W2K8R2 fails (heh heh :-). This is because we always cause
compound requests to get to a cancelation point before dealing
with a cancel request.
Jeremy.
Gets us handling SMB2 compound async requests similar to W2K8R2
(and triggers the same client bug in the Win7 redirector). Great
thanks to Ira Cooper <samba@ira.wakeful.net> for helping with
this and to Metze for the wonderful async framework. The one
thing I need to fix to make us identical to W2K8R2 is that
when a compound request goes async at the end W2K8R2 splits
the replies up into a compound non-async reply followed by
a separate async reply. Currently we're doing the whole thing
in a compound reply.
Jeremy.
