| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
reinit_after_fork() already calls messaging_reinit()
metze
|
| |
|
|
|
|
| |
The callers of open_file_ntcreate expect *psbuf to be filled correctly
|
|
|
|
|
| |
888524623d179ceb4d540f5ac0f3b013d3ce5735 broke the build. I'm
reverting it for the short term, while I work on a better fix.
|
|
|
|
| |
Jeremy
|
| |
|
|
|
|
|
| |
This fixes a series of samba3 build warnings in the merged build:
'error: "X" redefined', where X is one of the redundant #defines
|
| |
|
|
|
|
|
|
|
| |
This means we correctly pass IPv6 addresses too.
(CTDB_CONTROL_TCP_CLIENT was IPv4 only)
metze
|
|
|
|
| |
We allocated "request" with ippNew, so we also should ippDelete it.
|
|
|
|
|
|
| |
Without this, we end up adding more than one timed event. In the event handler
print_notify_event_send_messages() only one event will be deleted, all others
will fire indefinitely.
|
| |
|
|
|
|
|
|
|
|
| |
Incrementing the next vuid did not correctly overflow
Now we survive BENCH-SESSSETUP with -o 100000. Takes a while though :-)
Thanks a lot to Ofer Tal <otsmb@shmoop.org> for reporting #5933
|
|
|
|
|
|
|
|
|
|
| |
Ofer Tal <otsmb@shmoop.org> fully correctly noted that we're incrementing
num_validated_vuids twice per session setup, but decrement it only once.
Looking at sesssetup.c we always call register_initial_vuid() before
register_existing_vuid(), so there's no point in incrementing it in
register_existing_vuid().
Jeremy, please check!
|
| |
|
|
|
|
| |
get_valid_user_struct_internal() checks for UID_FIELD_INVALID itself
|
| |
|
|
|
|
| |
invalidate_vuid takes care of removing the user_struct from validated_users
|
|
|
|
| |
metze
|
|
|
|
|
|
|
|
| |
winbind_idmap.tdb
This upgrades the TDBSAM_VERSION to 4 and SAMU_BUFFER_V4.
metze
|
|
|
|
|
|
|
| |
The upgrade is required because of the followin TDBSAM_VERSION
upgrade.
metze
|
|
|
|
|
|
|
| |
This marshalling isn't specific to tdbsam and it's
ugly to have the related functions in two different files.
metze
|
|
|
|
|
| |
deadtime hits without any files open. To enable long runtimes, open a file with
delete_on_close set.
|
|
|
|
|
|
|
|
| |
We don't need a full copy of ctdb...
If we want to readd cluster support,
we should just use a ctdb client library.
metze
|
|
|
|
|
|
|
| |
If we readd this later, we should share the code with
samba3 and make it async/non-blocking.
metze
|
| |
|
|
|
|
|
|
| |
It seems there are SMB servers around which can't cope with the write header
being sent in a packet of its own. With writev we keep the advantage of direct
writes, giving the kernel the chance to coalesce the write calls.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
All callers expect 0 an success and -1 on error.
metze
|
|
|
|
| |
* also modified --usage descriptions to be more accurate
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
reported by and based on a patch by Yasuma Takeda
<yasuma@osstech.co.jp>.
Jeremy.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
it again :-)
|
|
|
|
| |
Jeremy.
|
|
|
|
| |
Jeremy.
|
|
|
|
| |
Jeremy.
|
|
|
|
| |
Jeremy.
|
|
|
|
| |
Jeremy.
|
|
|
|
|
| |
attribute warn_unused_result"
Jeremy.
|
|
|
|
| |
Jeremy
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|