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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
(This patch, only removing manpage text, submitted by gitlab.com user
Sam Zaydel @szaydel in MR 243 but without a Signed-off-by, so I
(Andrew Bartlett) am adding mine to say I'm happy to say this is a
legitimate and deliberate contribtion.)
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Sep 18 19:51:11 UTC 2019 on sn-devel-184
CUPS sanitizes argv[0] by removing username/password, so use
DEVICE_URI environment variable first.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14128
Signed-off-by: Bryan Mason <bmason@redhat.com>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Wed Sep 18 12:31:11 UTC 2019 on sn-devel-184
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Sep 18 01:26:06 UTC 2019 on sn-devel-184
share_mode_data->flags contains the "most restrictive" share mode of
the whole array. This is maintained lazily: Whenever set_share_mode()
is called, d->flags is updated if the new share mode got more
restrictive. It is not updated when a file is closed, as this would
mean we would have to walk the whole array, making sure that the
closed handle was indeed the only most restrictive one. Instead, we
walk the share mode array only when a conflict happens: Then we need
to know "the truth" and recalculate it by walking the share mode
array.
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 Sep 18 00:07:13 UTC 2019 on sn-devel-184
This will contain a summary of the "most restrictive" share mode and
lease, i.e. intersection of all share_access entries and the union of
all access_mask and leases in the share mode array. This way
open_mode_check in the non-conflicting case will only have to look at
the summary and not walk the share mode array.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This moves share_modes[] from "struct share_mode_data" into a separate
share_entries.tdb with a sorted array of fixed-length (132 byte)
"struct share_mode_entry" entries.
I know it's one huge commit, but I did not see a way to keep both data
structures and associated code working together without a lot of code
duplication after having centralized all the code accessing the
share_modes[] array into a few routines.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Samba so far on a dbwrap_watch record either watches or stores a
record, but never both from the same db_record instance acquired from
a dbwrap_fetch_locked(). In one of the next commits this will change,
we will watch a record and at the same time store data into it. This
patch enables a watch_send() followed by a storev() by properly
keeping the watchers around.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This goes directly into the database, for which the format changes
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Previously, we did this only when writing out the locking.tdb
record. That was because we had places where the index of a particular
share mode entry mattered while operating on the array. This is no
longer the case, so we can remove stale entries early.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
All places that matter explicitly check for staleness. This cleanup
action should only happen before writing the database
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
We have to break leases referenced from multiple share modes only
once.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The durable reconnect mainly has to check that there is one and only one
entry, and it has to reset it with the new values.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Avoid the full fsp, this makes the indexing of the share mode array
clearer, and it makes the next commit easier
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Why? Next commit will make share_mode_forall_leases() use
share_mode_forall_entries(), and that does not necessarily have to
depend on "share_mode_lock". And as we can pass the required
information via "private_data", don't embed the "share_mode_lock"
reference into this lowlevel library routine.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
It does not have to depend on the whole struct share_mode_data.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Abstract away the fact that we store the share modes as an array inside
"struct share_mode_data".
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Make the real data dependencies clearer, we don't need a full
share_entry, only its access and sharemode masks
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
It was hard for me to understand share_conflict(), so once I understood
it I thought this version would be easier to follow. It violates
README.Coding (one argument per line), but grouping the parameters to
mask_conflict makes it clearer to me what belongs together.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Mind the missing space before "(e.g. another...". While there, avoid
casts.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>