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 appears some newer versions of windows return
NT_STATUS_OBJECT_NAME_NOT_FOUND on a createfile when access is denied
rather than NT_STATUS_ACCESS_DENIED. I'm not sure how this translates
to directory enumeration yet, but for now make this a parameter that
can be checked in the various torture tests.
This also gets RAW-ACLS and SMB2-CREATE passing against win7.
- Change RAW-ACLS test suite so each test can be run individually.
- Add verify_sd() and verify_attrib() helper functions.
- Change test_nttrans_create() to work for both files and directories.
- Fix a segfault in test_inheritance() when the test errors out early.
- test_sd_get_set() does not pass against XP or Vista, so it is no longer added
to the RAW-ACLS test suite.
- Minor fixes to test_inheritance().
- New INHERITFLAGS test, which tests the auto inheritance flags a bit more.
- printf -> torture_comment / torture_warning / torture_result
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.
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
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.
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.
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.
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.
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
* 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.
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.
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.
The Samba3 internal notify code doesn't work correctly when there is
more than one tree connect to the same smbd process. This change to
the RAW-NOTIFY test triggers the bug.
typo goes to.....
Tim Prouty !!!!
Sorry Tim, nice test but you made a typo in passing in
the size of an array so we were reading uninitialized
memory :-).
That took far longer than it should have to track down...
(%$&#ing build system....).
The build farm should now slowly go back to normal.
Jeremy.
Inside a directory, keep a file open and then renaming
the directory should fail with ACCESS_DENIED. This
is connected to the test case where the close was
failing due to a delayed write on a file not being
able to succeed when Samba allowed the containing
directory to be renamed.
I will fix this in the server shortly (this should be done
across connections also but with will be very hard
in Samba - would need a full scan of the open file
db on every directory rename) - so I will fix for
the local case first (scanning local file opens
inside an smbd is cheap).
Jeremy.
* This adds a test to check the change notify behavior of the SMB server
when more events have been generated than can be returned in a single
change notify response.
* Second test makes sure the server doesn't return notification events
for changes to the watched directory itself
This tests how streaminfo deals with large buffers
smbclient seems to have problems when the buffer size approaches the
max data size. Also smbclient exposes no way to specify the max data
size that is sent in a trans2 request. Instead it hardcodes in a much
larger max than windows uses. For these reasons this test isn't
actually run, but is more of a reference for how windows handles
streaminfo buffers.
This allows the RAW-STREAMS test to work again. We still have some
limitations though:
- renames of a stream to the default stream doesn't work
- delete on close handling between streams and the main file
is still broken
There is one part of the new rename tests that passes against windows,
but doesn't pass against samba3 right now. Windows allow renaming a
stream to the default stream, but none of the current streams module
support this. When this ability is added the check for samba can be
removed from this test.
This patch also adds a missing unlink in the cleanup of
test_stream_delete and changes the order that the tests are run to be
consistent with the physical order in the file.
Eventually, we should move some of these parameters into a separate
struct (perhaps into smb_transport_options?), to avoid the long lists of
parameters.
This test assumed that fnums are recycled immediately after a close. This is
not true on Samba 3.
Andrew B., I assume this is just a bug in the test. Assuming recycled fnums
might be true on Windows and Samba 4, but I don't think we should assume this
everywhere.
Volker
(This used to be commit a4c3a59d47)
Also in particular the 'sync' flags (which Samba has traditionally
ignored).
Thanks to Olivier Salamin <olivier.salamin@gmail.com> for pointing out
more flags that needed to be handled.
Andrew Bartlett
(This used to be commit 370bb39cd7)
The MS-SMB document explains that some of these options should be
ignored. The test proves it.
/* Must be ignored by the server, per MS-SMB 2.2.8 */
/* Must be ignored by the server, per MS-SMB 2.2.8 */
If we implement HSM in samba4 (likely) we should honour this bit.
/* Don't pull this file off tape in a HSM system */
Andrew Bartlett
(This used to be commit 502739ff90)
Add a simple test to benchmark the rate at which a server can accept
new tree connections. You can tune the length of time to run the
benchmark for and the number of parallel connections to make.
(This used to be commit ea3f4b9305)
