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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
Do not attempt to delete streams on a truncating open, if the name
we're opening is itself a stream.
Port 176e8857203944bc332844b700749120ce90c891 to standard open path
Previously, we didn’t call SMB_VFS_OPEN_DIR from the streams module,
instead we called fdopendir(). As a result we failed to populate the
dir_state list in the readdirplus module. So when we tried to view the
stream data, we will always returned NULL.
To solve this I separated onefs_opendir() and the initialization of
the dir_state list. This is done by introducing a new utility function
“onefs_rdp_add_dir_state()”, which initializes the dir_state structure
and adds it to the dir_state list. This function is called from the
streams module before calling readdir().
This was uncovered when the MAX FD limit was hit, causing an instant core
and invoking error reporting. This fix causes SMBD to exit, but without
building a core.
This commit adds a configure argument which allows for setting MADV_PROTECT
in the madvise() API. With this enabled the kernel won't kill SMBD when
it's running low on memory.
Our packet layer relies on the event system reliably telling us when a
packet is available. When we are using a socket layer like TLS then
things get a bit trickier, as there may be bytes in the encryption
buffer which could be read even if there are no bytes at the socket
level. The GNUTLS library is supposed to prevent this happening by
always leaving some data at the socket level when there is data to be
processed in its buffers, but it seems that this is not always
reliable.
To work around this I have added a new packet option
packet_set_unreliable_select() which tells the packet layer to not
assume that the socket layer has a reliable select, and to instead
keep trying to read from the socket until it gets back no data. This
option is set for the ldap client and server when TLS is negotiated.
This seems to fix the problems with the ldaps tests.
This fixes two things in the TLS support for Samba4. The first is to
use a somewhat more correct hostname instead of 'Samba' when
generating the test certificates. That allows TLS test clients (such
as gnutls-cli) to connect to Samba4 using auto-generated certificates.
The second fix is to add a call to gcry_control() to tell gcrypt to
use /dev/urandom instead of /dev/random (on systems that support
that). That means that test certificate generation is now very fast,
which was previously an impediment to putting the TLS tests on the
build farm.
