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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It's better to have durable handles and multichannel tested separate:
1. we test both cases in the server
2. it makes it easier to deal with knownfail entries if only one
of these features is active on the server.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Guenther Deschner <gd@samba.org>
This implements a test that checks for the specified behaviour.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This test checks the SMB 2.1.0 behaviour of lock sequence checking,
which is only turned on for resilient handles.
Even Windows Server 2019 only implements lock sequence checking only
for resilient and persistent handles as a server.
While its client side uses lock sequence checking if it negotiated
multichannel with the server.
Hopefully this will be fixed in future Windows versions.
Make it clear that this test is supposed to pass against the legacy
Windows servers which violate the specification:
[MS-SMB2] 3.3.5.14 Receiving an SMB2 LOCK Request
...
... if Open.IsResilient or Open.IsDurable or Open.IsPersistent is
TRUE or if Connection.Dialect belongs to the SMB 3.x dialect family
and Connection.ServerCapabilities includes
SMB2_GLOBAL_CAP_MULTI_CHANNEL bit, the server SHOULD<314>
perform lock sequence verification ...
...
<314> Section 3.3.5.14: Windows 7 and Windows Server 2008 R2 perform
lock sequence verification only when Open.IsResilient is TRUE.
Windows 8 through Windows 10 v1909 and Windows Server 2012 through
Windows Server v1909 perform lock sequence verification only when
Open.IsResilient or Open.IsPersistent is TRUE.
Note <314> also applies to all versions (at least) up to Windows Server v2004.
Hopefully this will be fixed in future Windows versions and they
will avoid Note <314>.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The test was wrong in that it used an invalid
lock sequence bucket (65) where it actually wanted
to use a valid on (64), and hence the test results
(which were adapted to the real responses) were not
quite logical.
This patch fixes this and also improves some of
the comments so that the flow of the patch becomes
a little more obvious.
Pair-Programmed-With: Günther Deschner <gd@samba.org>
Signed-off-by: Michael Adam <obnox@samba.org>
Signed-off-by: Günther Deschner <gd@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
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): Thu Oct 20 02:48:30 CEST 2016 on sn-devel-144
This tests for a possible deadlock between smbd and ctdb dealing with
ctdb tombstone records.
Commit 925625b528 explains the deadlock in
more details and contains the fix. It's a fix for a regression
introduced by the patch for bug 10008 (1cae59ce11).
If you ever want to use this test against that specific commit:
$ git checkout 925625b528
$ git cherry-pick THIS_COMMIT
This should not deadlock on a ctdb cluster.
$ git revert 925625b528
This will deadlock.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=12005
Pair-Programmed-With: Michael Adam <obnox@samba.org>
Signed-off-by: Ralph Boehme <slow@samba.org>
Signed-off-by: Michael Adam <obnox@samba.org>
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Anubhav Rakshit <anubhav.rakshit@gmail.com>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
If we have more than one lock and there is any blocking lock, we need
to fail with NT_STATUS_INVALID_PARAMETER. At a quick glance I did not
find this tested, so add it.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Most Windows versions have a strange order to
verify the session id, tree id and file id.
(They should be checked in that order, but windows
seems to check the file id before the others).
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Wed Sep 28 21:12:07 CEST 2011 on sn-devel-104
This is consistent with the test names used by selftest, should
make the names less confusing and easier to integrate with other tools.
Autobuild-User: Jelmer Vernooij <jelmer@samba.org>
Autobuild-Date: Sat Dec 11 04:16:13 CET 2010 on sn-devel-104
The signed/unsignedness does match (always unsigned). The bitlength (64 bit) on
all regular platforms does also. Therefore simply add a cast to
"unsigned long long".
* test that 2 locks in a single LockAndX are transactional
* test that 1 unlock and 1 lock in a single LockAndX are not
transactional
* test that SMB2 doesn't like mixed lock/unlock in a single
PDU
s4 returns NETWORK_NAME_DELETED if you attempt to use an invalid tree connection
for a lock. This test (correctly I think) happens before we validate the file handle.
That implies that when you pass both a closed handle and a invalid tree you
should get NT_STATUS_NETWORK_NAME_DELETED.
I think the error/success codes returned by windows for these tests
are quite bogus. The ones s4 gives are much more reasonable. The
locking ones returning NT_STATUS_SUCCESS could lead to data loss, as
an application thinks it has a file locked correctly when it fact it
doesn't, so it could do an unsafe modify.
The BRL tests previously based their results off several bugs in the
W2K8 byte range lock code. I've fixed up the tests to pass against
Win7 which has fixed these bugs, and assume that the Win7 behavior
is the default.
I have inverted the test behavior for >63-bit lock requests. The
tests previously expected NT_STATUS_OK as their default in this
case. I've changed that default to expect STATUS_INVALID_LOCK_RANGE.
This may requires some changing of make test to compensate.
I've also removed a few test scenarios from VALID-REQUEST in preparation
of replacing them with separate tests ported from RAW-LOCK.
- SMB2 locking is different in several ways from SMB locking. To fix
it properly we will need a new generic mapping structure for
locking, but for now do a best effort mapping
- added locking to gentest_smb2
(This used to be commit ea6d9cf602)
- add modify the SMB2-LOCK-BLOCK-WRITE test to also test reading
and name in SMB2-LOCK-RW-EXCLUSIV
- add SMB2-LOCK-NONE and SMB2-LOCK-SHARED
metze
(This used to be commit 258555975d)
a write on a different file handle.
SMB2-LOCK-BLOCK-WRITE
- make it possible to run each SMB2-LOCK-* test on its own
metze
(This used to be commit 9c02f690bc)
