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
Using ldb unique indexes for samAccountName doesn't work with DRS as
the other DC may send us a deleted record (tombstone record), which
has the same samAccountName as an existing record. That would then
create two records in the same partition with the same samAccountName.
So we needed to put back the logic in samldb.c which explicitly
checked whether a samAccountName already exists on add
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
The LDB_ERR_NO_SUCH_OBJECT varient is not a defined variable. This
should improve error handling in our python code on some
systems. Unfortunately it still doesn't work on mine. I need to trap
Jelmer somewhere where he can't escape some day and force him to
divulge the deep druid secrets of python exception handling ....
The previous code incorrectly assumed that attributes such as
subClassOf come over the wire as strings. In fact they come over as 32
bit integers which refer to goversIDs. We have to post-process these
as it sometimes happens that a governsID comes over the wire before
the record that defines what it means.
- This changes the attribute "forceLogoff" to its' default
values according to Windows Server 2003 R2
- Also this corrects the "subRefs" attribute of the base-DN which only refers
to direct child partitions (and therefore not to the complete transitive closure)
These changes follow from the discussions on samba-technical. The
changes are in several parts, and stem from the inherent ambiguity
that was in talloc_free() and talloc_steal() when the pointer that is
being changes has more than one parent, via references.
The changes are:
1) when you call talloc_free() on a pointer with more than one parent
the free will fail, and talloc will log an error to stderr like this:
ERROR: talloc_free with references at some/foo.c:123
reference at other/bar.c:201
reference at other/foobar.c:641
2) Similarly, when you call talloc_steal() on a pointer with more
than one parent, the steal will fail and talloc will log an error to
stderr like this:
ERROR: talloc_steal with references at some/foo.c:123
reference at other/bar.c:201
3) A new function talloc_reparent() has been added to change a parent
in a controlled fashion. You need to supply both the old parent and
the new parent. It handles the case whether either the old parent was
a normal parent or a reference
The use of stderr in the logging is ugly (and potentially dangerous),
and will be removed in a future patch. We'll need to add a debug
registration function to talloc.
A dcerpc request may have a reference from a still completing async
callback, but we now consider the request to be complete. We want to
lose the main parent, leaving just the reference, if any.
The previous code caused memory leaks, and also caused situations
where talloc_free could be called on pointers with multiple parents
The new approach is to have two functions:
py_talloc_import : steals the pointer, so it becomes wholly owned by
the python object
py_talloc_reference: uses a reference, so it is owned by both python
and C
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>
