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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
