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 is an option for file systems that do not implement xattrs: in
lockdir/eas.tdb an array of xatts per inode is stored.
It can not solve the problem that xattrs might reappear if a posix-level
process deletes a file and happens to re-create it under the same name. On file
systems with birthtime we might have a chance to detect this, but not with
standard posix. A future version might put relief on file systems that do have
xattrs but where these are severely limited in size/speed/whatever: We can put
a simple marker as a native xattr, but the xattrs proper are stored in the tdb.
Volker
(This used to be commit 2036b4c5ad677b8a477b34b0f076febab0abff5e)
I know this will be overwritten by the next "make idl", but it just bugs me
*now* :-)
Volker
(This used to be commit a0abb885214ed29659889e359aecb60fb6dec100)
bugs in various places whilst doing this (places that assumed
BOOL == int). I also need to fix the Samba4 pidl generation
(next checkin).
Jeremy.
(This used to be commit f35a266b3cbb3e5fa6a86be60f34fe340a3ca71f)
could have happend with [in,out,unique] pointers
when the clients sends a valid pointer, but the server
reponse with a NULL pointer (as samba-3.0.26a do for some calls).
I've tested with midl to see how windows handles this situation
and also the reverse case where the client sends NULL and
the server reposnse with non-NULL.
It appears that midl generated code just ignores this
and only copies the result if both pointers are non-NULL.
metze
(This used to be commit cb98869fa189ce2a926a00fa9077a114f31a5d45)
and make that the primary context for the request
which the implementations can also use.
- go via functions pointers in the ndr_interface_table
instead of calling functions directly.
metze
(This used to be commit 5c4d998300d0c9836eb3cc6c3cd8ee4f262396b8)
rename dcerpc_interface_table -> ndr_interface_table
rename dcerpc_interface_list -> ndr_interface_list
and move them to libndr.h
metze
(This used to be commit f57d23d0f1b1c7a435f3a4ad801e58519cc92a77)
rename struct dcerpc_endpoint_list/struct dcerpc_authservice_list
into ndr_interface_string_array and move it to libndr.h
metze
(This used to be commit 9fec0d6c2ceaf66752baa5c8a34821bef2c5b833)
rename struct dcerpc_interface_call -> struct ndr_interface_call
and move it to librpc/ndr/libndr.h
metze
(This used to be commit 24e096b3659c3070a1ce029174fba51ae59e89ad)
doing this because for the clustering the marshalling is needed in more
than one place, so I wanted a decent routine to marshall a message_rec
struct which was not there before.
Tridge, this seems about the same speed as it used to be before, the
librpc/ndr overhead in my tests was under the noise.
Volker
(This used to be commit eaefd00563173dfabb7716c5695ac0a2f7139bb6)
add [ref] pointers where necessary (top-level [ref] pointers,
by spec, don't appear on the wire).
This brings us closer to the DCE/RPC standard again.
(This used to be commit 580f2a7197b1bc9db14a643fdd112b40ef37aaef)
With more than 5 different trees I can't swear that I did test this properly
yesterday. Sorry for the noise.
Volker
(This used to be commit 978a6196bf0a2280c7f74b4a6d9fa7941c3aa049)
other StringBufs, otherwise clicking on a key with this value being set leads
to regedit.exe on w2k3 chew all memory.
(This used to be commit b148cde7f39859102288a87b6f0bd2b250947a85)
