Age | Commit message (Collapse) | Author | Files | Lines |
|
The code to read the new V2 SAMBA_PAI entries had
two errors.
Jeremy.
|
|
Guenther
|
|
Guenther
|
|
This reverts commit 17ef153b68795fec681f9ce17c198236aba2b1c2.
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
impersonation.
Guenther
|
|
Guenther
|
|
Guenther
|
|
Guenther
|
|
BASE-DELAYWRITE and also RAW-CLOSE.
Jeremy.
|
|
the logic. This was incorrect (I'll revisit this tomorrow).
Jeremy.
|
|
explain why you added this. Change --maximum-runtime=900 for smbtorture4
with BASE-DELAYWRITE. Should allow it to successfully complete now.
Jeremy.
|
|
set_close_write_time().
We were treating a file time set on close as a sticky write time set, and I don't
think it is. I will add a torture test later to RAW-CLOSE to confirm this.
Jeremy.
|
|
Jeremy.
|
|
"Normal" non truncate writes always cause the timestamp to
be set on close. Once a close is done on a handle this can
reset the sticky write time to current time also.
Updated smbtorture4 confirms this.
Jeremy.
|
|
|
|
We want to free the record early, not when talloc_tos() is free'ed.
|
|
When something in the cluster blocks, it can happen that we wait indefinitely
long for ctdb, just adding to the blocking condition. In theory, nothing should
block, but as someone said "In practice the difference between theory and
practice is larger than in theory". This adds a timeout parameter in seconds,
after which we stop waiting for ctdb and panic.
|
|
Signed-off-by: Bo Yang <boyang@samba.org>
|
|
Jeremy.
|
|
using older protocols (LANMAN2 or below).
Jeremy.
|
|
Jeremy.
|
|
setting nanosecond timestamps using utimensat() was first supported by Linux
kernel 2.6.22 and glibc 2.6. It's specified in POSIX.1-2008.
This effectively makes us use Windows' full 100ns timestamp resolution -
actually just an improvement from 10^-6 to 10^-7.
For now Linux CIFS vfs will also just be able to make use of 100ns resolution,
not 1ns.
|
|
This aims to eventually share this with Samba4.
Andrew Bartlett
|
|
_netr_LogonControl2Ex().
Guenther
|
|
Guenther
|
|
friends as well.
Guenther
|
|
netr_LogonControl2Ex() and friends.
Guenther
|
|
Add dummys (just like s4 does) and fill in some more appropriate error codes.
Guenther
|
|
Guenther
|
|
Jeremy.
|
|
Jeremy.
|
|
not 4 byte aligned (levels 1 - 3).
Jeremy.
|
|
smbd just crashed on me: In a debug message I called a routine preparing a
string that itself used debug_ctx. The outer routine also used it after the
inner routine had returned. It was still referencing the talloc context
that the outer debug_ctx() had given us, which the inner DEBUG had already
freed.
|
|
Jeremy.
|
|
Don't only rely on dptr == NULL.
I stumbled over this one when rewriting some of the dbwrap_ctdb code.
Michael
|
|
regdb_fetch_keys_internal()
Prevents segfaults in some situations.
(For a non existent or empty record, we sometimes rely on the fetch operation
to return dsize==0 and sometimes we rely on dptr==NULL.)
Michael
|
|
for the case that another local process has started a transaction
bewteen releasing the transaction_lock record and starting the
transaction.
Michael
|
|
in db_ctdb_transaction_fetch_start() for error conditions when re-fetching
the transaction_lock record inside the transaction
Michael
|
|
node.
In ctdb_transaction_commit(), when the trans2_commit control fails, there
is a race condition in the 1 second sleep between the local transaction_cancel
and the call to ctdb_replay_transaction(): The database is not locked, and
neither is the transaction_lock record. So another client can start and possibly
complete a new transaction in this gap, but only on the same node: The locking
of the transaction_lock record on a different node which involves migration of
the record to the other node has been disabled by introduction of the
transaction_active flag on the db which closes precisely this gap from the start
of the commit until the call to TRANS2_FINISH or TRANS2_ERROR.
But this mechanism does not cover the case where a process on the same node
tries to start a transaction: There is no obstacle to locking the transaction_lock
record because the record does not need to be migrated.
This commit closes this race condition in ctdb_transaction_fetch_start()
by using the new ctdb_ctrl_transaction_active() call to ask the local
ctdb daemon whether it has a transaction running on the database.
If so, the check is repeated until the running transaction is done.
This does introduce an additional call to the local ctdbd when starting
transactions, but it does close the (hopefully) last race condition.
Michael
|
|
Michael
|
|
CTDB_CONTROL_TRANS2_COMMIT
Michael
|
|
There are two races in concurrent transactions on a single node.
One in starting a transaction and one with replay during commit.
This commit closes the first race by storing the client pid in the
transaction-lock record and comparing the stored pid against its own
pid after releasing the lock and refetching the record inside the
transaction.
Michael
|