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 allows a requestor to set FORCE_OPLOCK_BREAK_TO_NONE
to ensure we don't break to level 2. Fixed a couple
of resource leaks in error paths in open_file_ntcreatex.
Jeremy.
mid replies on path based set-eof trans2 calls.
Needs modification for HEAD (as in head open_file_ntcreateX
properly returns NTSTATUS - I'll fix this tomorrow my
time). Secondly it still fails the Samba4 RAW-OPLOCK
smbtorture because of an interesting case. Our oplock
code always returns "break to level 2" if it can.
In this case (path-based set-eof or set-allocation size
on an exclusive oplocked file) W2K3 always sends a
break-to-none. We send the break to none (from level2)
after we've done the write for eof or allocation size.
I need to work out some way of telling our break code
to always break to none (might need to extend the message
field).
Jeremy.
might pull in libpthread. This is quite bad, firstly because it can
cause oplock signals on Linux to go wonky, and secondly because merely
linking with pthreads can cause performance degradations due to implicit
locking requirements.
The solution is to only search for clock_gettime if --with-profiling-data
was specified. If we do end up searching for it, then we test whether
linking with librt pulled in libpthread, and we only allow the definition
for clock_gettime to succeed if libpthread was NOT linked in.
Problem reported by Thomas Bork and diagnosed by Volker Lendecke.
Fix more potential segfaults when something on our way to a DC connection
fails.
We can not continue if dcip_to_name() fails. With
192.168.234.100 nt4pdc
192.168.234.100 windows#1c
192.168.234.100 windows#1b
in the lmhosts file when nt4pdc is rebooted, we do find the DC's IP address,
we can connect to TCP 139 while it is booting but anything else fails. So we
fall back to put the IP address into domain->dcname. When the DC is fully up
later on we try to do the auth2 against \\192.168.234.100 which gives
INVALID_COMPUTER_NAME. And we never get out of this loop again.
Fix this.
Jerry, maybe you can take a look.
Thanks,
Volker
