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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We search in the schema if we have already this intid (using dsdb_attribute_by_attributeID_id because
in the range 0x80000000 0xBFFFFFFFF, attributeID is a DSDB_ATTID_TYPE_INTID).
If so generate another random value.
If not check if the highest USN in the database for the schema partition is the
one that we know.
If so it means that's only this ldb context that is touching the schema in the database.
If not it means that's someone else has modified the database while we are doing our changes too
(this case should be very bery rare) in order to be sure do the search in the database.
Samba 4 use to try to reload the schema every time dsdb_get_schema was
called (which could be 20+ time per ldb request). Now we only reload at
most every xx seconds (xx being the value of dsdb:"schema_reload_interval"
or 120). The timestamp of the last reloaded schema is kept in the
dsdb_schema object. There is also a timestamp in the ldb_context, that
is used by the LDAP server to know if it has to reload the schema after
handling the request. This is used to allow that the schema will be
immediately reload after a schemaUpdateNow request has been issued, the
reload can't occur in the handling of the LDAP request itself because
we have a transaction autostarted.
gpfs2smb_acl can leave errno!=0 around even if it returned a correct
result!=NULL. We can only rely on errno being set if another error
condition (in this case result==NULL) indicates an error. If
result!=NULL, errno is undefined and can be anything. This leads to
SAFE_FREE(result) further down even in the success case.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Fri Jun 22 19:27:39 CEST 2012 on sn-devel-104
samba checks tree before file, so we get a
STATUS_NETWORK_NAME_DELETED instead STATUS_FILE_CLOSED
when operating on a file handle on a invalid tree id.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
This way we can give anonymous full access to the directory.
metze
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Fri Jun 22 11:30:06 CEST 2012 on sn-devel-104
It's not portable. While we could use ccan/err, it seems overkill since
we actually only use it in one test (I obviously cut & paste the #include).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Autobuild-User(master): Rusty Russell <rusty@rustcorp.com.au>
Autobuild-Date(master): Fri Jun 22 09:22:28 CEST 2012 on sn-devel-104
(As suggested by Stefan Metzmacher, based on the change to ntdb.)
Since commit ec96ea690e, we handle the case
where a process dies during a transaction commit. Unfortunately, TDB_NOSYNC
means this no longer works, as it disables the recovery area as well as the
actual msync/fsync. We should do everything except the syncs.
This also means we can do a complete test with $TDB_NO_FSYNC set; just
to get more complete coverage, we disable it explicitly for one test
(where we override the actual sync calls anyway).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The flags returned were TDB-specific: this was only used for detecting
the endianness of obsolete databases (the conversion code was put in in
2003, with reference to Samba 2.3).
It's easier to remove it than to translate the NTDB flags to TDB flags,
and it's a really weird thing to ask for anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Similar to the util_tdb versions, but return the error code.
ntdb_add_int32_atomic seems a clearer name than tdb_change_int32_atomic.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Very similar to the util_tdb versions, but these return the error.
I've only implemented those functions actually used.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There are various issues with NTDB_CLEAR_IF_FIRST which makes it
better if we don't have to use it, but much of the code does, so
we fake up support here.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The first function is ntdb_new: this is preferred over ntdb_open, as
it makes the ntdb_context returned (and all NTDB_DATA returned from
ntdb_fetch) valid talloc pointers.
The API is very similar to tdb_wrap_open().
Note that we handle $TDB_NO_FSYNC here, since ntdb doesn't do that
hack (and it's great for speeding up testing!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, this tests that we can store enough records to make the
database expand while we map the given record. We use a global lock for
this, but it could happen in theory with another process.
It also tests the that we can recurse inside ntdb_parse_record().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we have a readlock, any write will grab a write lock: if it happens
to be on the same bucket, we'll fail.
For that reason, enforce read-only so every write operation fails
(even for NTDB_NOLOCK or NTDB_INTERNAL dbs), and document it!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
NTDB_INTERNAL databases need to malloc and copy to keep old versions
around if we expand, in a similar way to the manner in which keep old
mmaps around.
Of course, it only works for read-only accesses, since the two copies
are not synced.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means keeping the old mmap around when we expand the database.
We could revert to read/write, except for platforms with incoherent
mmap (ie. OpenBSD), where we need to use mmap for all accesses.
Thus we keep a linked list of old maps, and unmap them when the last access
finally goes away.
This is required if we want ntdb_parse_record() callbacks to be able
to expand the database.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we can have multiple openers, we should leave the mmap in place
for the other openers to use. Enhance the test to check the bug (it
still works, because without mmap we fall back to read/write, but
performance would be terrible!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Then we unset it inside the tdb test target itself. This means that
new code can't accidently forget it, and we can set it in the
'buildnice' script on sn-devel, for example.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>