Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Tim Prouty <tprouty@samba.org>
|
|
Signed-off-by: Tim Prouty <tprouty@samba.org>
|
|
Signed-off-by: Tim Prouty <tprouty@samba.org>
|
|
Signed-off-by: Tim Prouty <tprouty@samba.org>
|
|
Try a rename with a wide-open share mode on an already open file
and the there is still share mode contention. For the reason why
see:
http://social.msdn.microsoft.com/Forums/en-US/os_fileservices/thread/3ca14dc9-da1f-4786-a8f7-a86e9903db0c
Msft's anser:
After further review, The reason for server to fail with sharing
violation is that the windows server that executes a path-based
rename request opens the file for DELETE access, but only with
FILE_SHARED_READ as ShareAccess . Therefore, the existing
open(frame 76), which has shared read/write/delete , is compatible
with the Windows servers access mode (DELETE), but Windows servers
open is not compatible with access mode in existing open.
Note that it is correct to state that the logic in Windows server
could have been written to allow shared read/write/delete in which
case it would succeed as you mention. The behavior here is
historical based on the existing implementation.
|
|
|
|
Some servers choose to mark a client as bad if they fail an oplock
break request by timing out (win7 is an example). Once the client is
marked as bad, future oplock requests will timeout instantly. This
causes subsequent runs of this test to fail, so rather than erroring
out as a failure, a warning is printed instead.
There is also a bug in w2k3 where it was incorrectly returning
contending a share mode lock. It worked in XP and has been re-fixed
in win7.
This can also now be run against samba3.
|
|
|
|
breaks
|
|
See what happens when we have multiple outstanding lock requests and
we try to cancel both of them within a single LockingAndX.
On Windows, it seems only the first lock in the array is cancelled,
and the second is left pending. Though, this behavior goes against
the MS-CIFS spec.
|
|
* 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
|
|
|
|
Abstract the server requirements to pass some BRL tests.
* The new default for >64bit lock tests, is that the server should
return STATUS_INVALID_LOCK_RANGE.
* Add parameter for targets that don't implement DENY_DOS
|
|
In light of the INVALID_LEVEL that is seen for RAW_SFILEINFO_END_OF_FILE_INFO
requests on a path, I'm changing these back to using the passthrough
RAW_SFILEINFO_END_OF_FILE_INFORMATION to test the oplock break behavior as
originally intended
|
|
cases
It turns out setting the end-of-file with Trans2SetPathInfo using the
snia spec's info level will attempt to open the file, enforcing share
modes, but then subsequentlys fail the setpathinfo with a dos error of
INVALID_LEVEL. Doing a Trans2SetFileInfo with either end-of-file info
level succeeds as expected.
|
|
Since the windows behavior appears to be a bug, only check for
the windows-style share mode bug if target=<windows variant> is
specified
|
|
in multiple files
|
|
"discard_const_p"s
|
|
|
|
SET_END_OF_FILE_INFO
The passtrhough version of SET_END_OF_FILE_INFO is tested in
RAW-SFILEINFO-END-OF-FILE.
Additionally, the first opener is changed to use SHARE_WRITE for the
share mode since SET_END_OF_FILE_INFO actually writes data to the file
via truncating/extending.
|
|
These tests expose a potential bug in winXP, win7, and likely others.
There is also a bug in samba where share modes aren't being enforced
where they should.
For more details see:
http://lists.samba.org/archive/cifs-protocol/2009-November/001130.html
|
|
A side effect of this change is that RAW-SFILEINFO now runs the whole
suite instead of just the first test. I changed the name of the first
test to RAW-SFILEINFO-BASE and changed all of the selftest scripts
that call it.
|
|
start_timer/end_timer
metze
|
|
|
|
|
|
we need to file a CAR to find out why Windows gives INVALID_PARAMETER
for this.
Jeremy.
|
|
This reduces compile time somewhat.
|
|
In some cases we were not doing streams tests on s4 that we should. In
others, we were calling tests that are known to fail on s4. Some of
those are a bit puzzling.
|
|
please check.
Jeremy.
|
|
|
|
s4 returns group and world ACEs in the default acl, based on unix
permissions
|
|
|
|
lsa privileges calls don't expand groups. darn.
|
|
In order to implement root_fid in the s4 SMB server we need to declare
it as a handle type, just as for other fnum values in SMB. This
required some extensive (but simple) changes in many bits of code.
|
|
The BENCH-TCON test was leaving the socket open. A smbclie_tdis()
closes the tree connection, but does not close the socket.
This caused the build farm to run out of file descriptors
|
|
Jeremy.
|
|
|
|
* Add chained NTCREATEX_READX test which first tries to open/read
a non-existant file failing on the open, then attempts the same
operation on a file that does exist, opening and reading
successfully.
* Add test for open_dispositions on directories.
|
|
Allows "make test" and other harnesses to print cleaner output.
|
|
|
|
We were pulling junk memory for our stream names after the reordering
of the struct definition.
|
|
Previously, the oplock torture tests, being single threaded, required
the server to return oplock break requests, and other SMB packets
in a specific order for us to verify "correctness".
Of course, in several cases the protocol allows the break packets,
especially breaks to levelII to come back in any order. With tevent
we're now able to wait for oplock breaks in the middle of a torture
test.
I've added a helper to do this, and modified all oplock tests to allow
returning of oplock breaks in any order.
|
|
Allows "make test" and other harnesses to print cleaner output.
|
|
|
|
This allows RAW-STREAMS to pass when the user isn't root on some
systems that don't give full access rights to non-root users.
|
|
|
|
* test if oplocks are granted when requesting delete-on-close
* test how oplocks are broken by byte-range-lock requests
|
|
Allows "make test" and other harnesses to print cleaner output.
|
|
The existing test was only covering files opened underneath the
directory that was being renamed. It is not uncommon for windows
clients to actually hold a read-only handle to a directory open across
the rename, which it turns out doesn't return NT_STATUS_ACCESS_DENIED.
Additionally, holding a handle open to a stream on the directory is
also allowed.
|
|
|