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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
For sync replies it's not a problem, as construct_reply() will send
the response, but for async replies we would not send the reply to the client.
Currently the notify code works arround this manually, so I assume
we didn't have a bug here. But the next commits will simplify
the notify code.
metze
This is needed to prevent samba3 and samba4 from using an ABI
incompatible system version of talloc
See ongoing discussion on the samba-technical mailing list
consumed_ucs is the number of bytes
of the UCS2 path consumed not counting any
terminating null. We need to convert
back to unix charset and count again
to get the number of bytes consumed from
the incoming path.
Now that the sanity checks for mount.cifs default to matching the
behavior of /bin/mount, then there is virtually no need for umount.cifs.
The only exception is when someone enables the loose setuid behavior in
mount.cifs.
If an unprivileged user mounts a share that isn't in /etc/fstab, then
/bin/mount won't allow that user to unmount it. In that situation,
umount.cifs will be necessary to allow unmounting the share.
Signed-off-by: Jeff Layton <jlayton@samba.org>
Acked-by: Steve French <smfrench@us.ibm.com>
By adding a new common setup_logging_stdout() API, we no longer need to abuse the ABI compatability between the different setup_logging() calls in Samba3 and Samba4's DEBUG() subsystems.
The revert of 49a6d757b4 works with this
to fix bug 6211.
Andrew Bartlett
The search function retries once, the modifying call that hits a dead smbd
returns an error. The next try will reconnect. This was simple to implement and
provides a good compromise against Samba4 idling our connection. Most of the
modifying calls are quickly after a search (like OpenUser) anyway.
There have been some reports that we're flooding syslog with "No data on
inotify fd?!". I haven't been able to reproduce this yet. Until then, it is
better to just list this message once.
