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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As noted by Metzy, it makes no sense here to check id->sid.
What is worse, this might even be passed in uninitialized.
This still fixes the bug for me (of course), but we might need
to check, if another special handling of passdb is needed
(possibly changing from constant return code NT_STATUS_OK...)
Michael
Signed-off-by: Michael Adam <obnox@samba.org>
This failed for backends other than passed, since
idmap_backends_unixid_to_sid() always asked passdb first,
which returned Success no matter whether a mapping was
found or not.
One effect wast that getpwuid failed after "net cache flush".
Only after filling the cache with a getpwnam call it succeeded.
This fix makes the behaviour of idmap_backends_unixid_to_sid()
exactly the same as that of idmap_backends_sid_to_unixid()
Michael
Signed-off-by: Michael Adam <obnox@samba.org>
When there are enough streams on a file to fill up the max_data_count
when responding to a trans2 streaminfo, samba is returning
NT_STATUS_BUFFER_TOO_SMALL. Windows handles this by returning
NT_STATUS_BUFFER_OVERFLOW while still sending as much of the data that
it can fit into the buffer. When the windows client sees
BUFFER_OVERFLOW, it retries the streaminfo with a larger buffer (2x).
The windows client starts at 2K and will continue increasing the
buffer size by two until it reaches 64K. If the streams don't fit in
64K the windows client seems to give up.
This patch fixes marshall_stream_info to overfill the buffer by 1
stream so that send_trans2_replies can properly detect the overflow
and return the correct status.
If it takes more than 10 seconds to understand the code you've written yourself
less than a year ago, it's time for comments or refactoring. I couldn't find a
way to refactor that cleanly, so add comments :-)
If we really want to keep the pipe busy, we need to write everything we have as
early as possible, giving the kernel the chance to get rid of the buffers
quickly :-)
