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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
get_lease_type() can involve a database access. Do that only if
necessary, and that is at most once in this loop.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Böhme <slow@samba.org>
* Assign *file_created on every exit.
* Directly assign curr_flags without &= / |=
Both of these changes make the routine easier to understand for me,
less jumping around in the code to see where the values came from.
* Do the retry in a "positive" if-clause
Normally I'm a big fan of early returns, but this single retry is so
simple that to me it's easier to understand this way.
Overall, 13 lines less code. YMMV :-)
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Sat Aug 10 00:07:28 UTC 2019 on sn-devel-184
I don't really have a test case, but to me a positive test for a
regular file makes more sense here than just ruling out FIFOs. While
we probably only ever hit regular files (or FIFOs), there might be
more that we catch and don't properly handle.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is the one place where *lease actually got modified. We can
easily make a copy, "struct smb2_lease" is not too large, and this
case is pretty rare anyway.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Simplify the flow in open_file_ntcreate, streamline it for SMB2
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is close to what Windows SMB1 does: Instead of waiting for the
share entry causing the SHARING_VIOLATION to disappear, retry every
200msec up to one second. Windows does it a little differently: Retry
up to 5 times. But up to one second should be close enough.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is necessary for the following case:
We want to delete a file with an open stream that is not open with
FILE_SHARE_DELETE. In SMB1, we need to defer the sharing violation
reply (we don't do that right now, test to follow). However, when we
move that sharing violation delay to where it belongs, into the outer
layers, only very deep in the nested open_streams_for_delete smb1
sharing violation delay handling call we will hit the sharing
violation in the 1-second retry case. However, that
open_streams_for_delete itself is INTERNAL_OPEN_ONLY and thus not
deferred itself. This means that it will not overwrite
req->request_time at all.
Exec summary: We only have one request_time now, set it properly as
early as possible.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This will become important in the next commits when the SMB1 sharing
violation delay will use this. We want to be able to reduce the
timeout to less than 200msec, see the next commits.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is for callers who don't want to call open_was_deferred()
afterwards
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is a generic "open retry without locking.tdb waiter" loop: Take
the specific timeouts as parameters.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Failure to postpone a request is not really fatal: We just don't retry
as wanted but return an error to the client that might have resolved
itself after a few seconds. From my point of view such a spurious and
rare error, which is highly unlikely anyway does not justify to kill
that client's connection.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This piece of code predates our user-space access checks, which we
nowadays always do in open_file()
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Slightly simplify assumptions in the code
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Aug 6 23:06:41 UTC 2019 on sn-devel-184
This hides a talloc off the NULL context: The caller needs to make sure
this is put on a real talloc context later. Make that more
obvious. Also, it passes down a boolean flag, making its purpose a bit
opaque to the caller sites.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The fsp carries all required information also for leases. There's no
need to pass that as additional parameters
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Nobody used this (except vfs_gpfs, which did not need it really). If
you *really* need this, you can always look in locking.tdb, but this
should never happen in any hot code path, as no runtime decisions are
made on the share access after the open is done.
Bump VFS interface number to 42.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Why? While restructuring open_file_ntcreate() I found the data flow for
these values confusing: grant_fsp_oplock_type() depends on
fsp->access_mask, which changes its value inside
open_file_ntcreate(). I find the data flow easier to follow if it
happens in explicit variables.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Makes the interface more obvious to me. Also, I want to remove
fsp->share_access, which is not really used anywhere after the fsp has
been fully established.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
For whatever reason, "st_size" in "struct stat" is an off_t, which is a
signed integer. Negative sizes don't really make sense, so this cast
should be safe.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
In the 2nd for-loop we need a signed int as we are comparing to >=0.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
It seems more natural to pass in a request to a routine called
request_timed_out(), and it's a few bytes less .text
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We have "smb_request->request_time" that is already set up by
init_smb_request().
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This now removed comment describes the bug correctly:
/*
* As this timer event is owned by req, it will
* disappear if req it talloc_freed.
*/
In smb1, "req" disappears once the reply_whatever routine is done. Thus
the timer goes away and we never look at "req" again.
This change moves the valid data (xconn and mid) to
deferred_open_record, and changes the talloc hierarchy such that the
timer is now a child of open_rec, which is a child of the deferred
message.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=14060
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Jul 31 00:12:34 UTC 2019 on sn-devel-184
It's perfectly possible that someone else takes a kernel oplock and
makes us block, independent of our own kernel oplock setting.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=14060
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is SMB1-only and pre-ntcreate with only 3 callers that look at
NTCREATEX_OPTIONS_PRIVATE_DENY_[DOS|FCB]. It is a bit less efficient
if it kicks in (we have to recreate the fsp), but SMB1 is less and
less popular, and this particular share mode combination from the
open&x family of calls might not be worth optimizing for.
This adds smb1_utils.[ch] as a kitchen sink for functions that can go
away once we drop SMB1.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
If there are no share modes, we'll just not enter the loop.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
