Age | Commit message (Collapse) | Author | Files | Lines |
|
Guenther
(This used to be commit 3b87c5ce4f74f8dd01bfdf8859c6c832da15cd24)
|
|
Guenther
(This used to be commit 0230284cfa83477ad5a084a7970db1ea0cfe8563)
|
|
Guenther
(This used to be commit b4c1904022cd34c239f163d49d5a13925d238cda)
|
|
Guenther
(This used to be commit 5d8e5cbc3b3ddd1c5788d66f252e4801739243bb)
|
|
Guenther
(This used to be commit b0e86c5b4d375f21f06208dc063adb9d2659d30b)
|
|
(This used to be commit 48288869d314d8c91d07282b5536b231d95db159)
|
|
(This used to be commit 35d71a40b385a62b8c85ed68e64b6d38d80aeb3c)
|
|
(This used to be commit a6677b2e186212f723b24775293682ce5b94952e)
|
|
Guenther
(This used to be commit d9c8a2271d5d4ff845f1fe5986a2c63d79c41415)
|
|
Guenther
(This used to be commit d94bd3a03b574b3fdddd62add25b0c04673500a3)
|
|
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)
|
|
Guenther
(This used to be commit 94693755a291993217b5cb74794504a8593eae30)
|
|
Guenther
(This used to be commit 33f6eff92b6bdf804d54c84375cece8a867933f2)
|
|
Guenther
(This used to be commit add28753b2e740804c48db5f6235cb2f8908d82b)
|
|
(This used to be commit 7e75acfdd1910b3b5908c02d5f343f014eb77841)
|
|
Guenther
(This used to be commit 6169dea4dc3c4fc5eb1caefde828ed896cf048c5)
|
|
Guenther
(This used to be commit 3d34c87612138e4457e824e1a6e3981d1c3fe238)
|
|
Guenther
(This used to be commit d1fa8049b1c0a3cebbc2c64e245e8055c8d3e84b)
|
|
I know this will be overwritten by the next "make idl", but it just bugs me
*now* :-)
Volker
(This used to be commit a0abb885214ed29659889e359aecb60fb6dec100)
|
|
Guenther
(This used to be commit 8a1b306b826c75dde9caadc93b022bfa9bf3c4e3)
|
|
Guenther
(This used to be commit 298b0ce951f02705c5660a4171f7cc208de7a1db)
|
|
Guenther
(This used to be commit 7539fb4c840a9b4429f347cebbda9c631746267a)
|
|
metze
(This used to be commit 53a636828d2ba01603401086f4a5f72f9b5ea214)
|
|
metze
(This used to be commit 83b3ecde1312092fd9875a2a8628652ffa6b6aca)
|
|
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)
|
|
metze
(This used to be commit af91f4fd08aae117d9b48eade4d49762c9634cbc)
|
|
metze
(This used to be commit 5514e8487fee453b730a966ebc6fcdcd56da047a)
|
|
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)
|
|
instead of the pull and push functions
metze
(This used to be commit 5e3d4df9bca069708d72f548dc5ddfc7708ac122)
|
|
metze
(This used to be commit ec8858c37482f0d2ac1291d9a9df00dace6944a8)
|
|
rename some DCERPC_ prefixes into NDR_
metze
(This used to be commit 8f07b8ab658ae3d63487ca5fb20065318cdd9d0e)
|
|
rename 'dcerpc_table_' -> 'ndr_table_'
metze
(This used to be commit 4e5908cd596f97d3bb73bd9c0bf3d360944f7810)
|
|
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)
|
|
metze
(This used to be commit e827c7311ce9890358be145099391c6b3cee15a1)
|
|
fixes winreg_EnumValues()
metze
(This used to be commit cedf7022c5c61ed5eb49bb1cb24b062858f7d2fd)
|
|
<gepardcv@yahoo.com> for checking.
(This used to be commit 84b8a56fe9aef1e0583cf5f5abb037199cf21fd9)
|
|
Guenther
(This used to be commit 71b3259962004c278ca2e859d5460ad47c2468d6)
|
|
(This used to be commit 92c505bf7f15a79c6e32a38b2d218f65b0283507)
|
|
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)
|
|
(This used to be commit ad981261877e6a2dce0c4f4e71fd9127aa31538a)
|
|
(This used to be commit 7fdbf66976fa1b43eabca4786844a41a4381b3ef)
|
|
(This used to be commit 9a9b9421673ed1c455658d8ae79d7a1522a1baa7)
|
|
(This used to be commit 952f648d8132a0652bb03b9e7671239e57614ee9)
|
|
(This used to be commit e73a418b5b0100936efb4c1133da3cfe3fcb61cd)
|
|
(This used to be commit b84370513fbf790e599c33f177fb271a2a992b72)
|
|
(This used to be commit 1dc2ba09c7afc516d894fddfed613990ccf1f1ee)
|
|
and the
resulting marshalling/unmarshalling routines in gen_ndr/
Volker
(This used to be commit a2ea54c23456925a8ed317edb1adf82d074041fc)
|