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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Also remove ads_memfree(), which was only ever a wrapper around
SAFE_FREE, used only to free the DN from ads_get_ds().
This actually makes libgpo more consistant, as it mixed a talloc and a
malloc based string on the same element.
Andrew Bartlett
Signed-off-by: Günther Deschner <gd@samba.org>
Why?? :-)
Another one of the little micro-optimizations that I just came across: If you
allocate a variable in a sub-block like the "fstring sharename" in
write_file(), gcc even with -O3 will allocate this variable unconditionally on
the stack at the beginning of the routine. So with eliminating this fstring we
cut 256 bytes of stack in a very hot code path writing to a file. It might make
us a bit more cache-friendly.
This would probably not be worth a second look if it involved larger code
changes, but this one was just too simple to let it pass :-)
This took me almost a week to find, so here a little longer explanation:
When a windows client registers printer *status* change notifies using
spoolss_RemoteFindFirstChangeNotify, it registers them to a print server handle,
not a printer handle. We were then correctly monitoring the printer status
changes but were sending out the spoolss_RouterReplyPrinterEx via the back-channel
connection with job_id set to 0 (which we only may do for monitored printer
change status notifies on printer handlers, not print server handles). Windows
was then showing a new empty dummy printer icon in the explorer as it cannot
route the notify event to the approriate local handle. It also discarded the
content of the notify event message of course. With this, printer change notify for
pausing, resuming and purging printers nicely works again here.
Jerry, Tim and all other printing gurus, please check.
Guenther
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.
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.
