09/01/10 0:00:22 my buildbot says the build broke about 12 hours ago, and is still broke. 09/01/10 0:00:29 I only have 2 hour granularity though. 09/01/10 0:01:20 ah yes, still broken 09/01/10 0:16:32 Signoff: jelmer (Ping timeout: 258 seconds) 09/01/10 0:31:16 Signoff: ptramo (Read error: Connection reset by peer) 09/01/10 0:37:04 |Kellan| (~kellan@69.38.223.178) has joined channel #samba-technical 09/01/10 0:39:07 ita: got a few minutes 09/01/10 0:39:08 ? 09/01/10 0:39:35 bradh: yes? 09/01/10 0:40:02 http://git.samba.org/?p=samba.git;a=commitdiff;h=c091b3344badac6241b85c6cf2f7dacb0f06047c was bj's add of the monotonic clock functions. 09/01/10 0:40:26 that looks like it went into the LIBSAMBA-UTIL subsystem. 09/01/10 0:40:46 however when I try to refer to that in the ldb build, I get 09/01/10 0:40:55 Unknown dependency LIBSAMBA-UTIL in ldbtest.objlist 09/01/10 0:41:29 hmm err, the build breaks on krb5/time.c and v4_glue.c, doesn't it? 09/01/10 0:42:05 ita: I'm not getting that far. 09/01/10 0:42:15 OpenChange needs a standalone build of ldb 09/01/10 0:42:25 ah! 09/01/10 0:42:43 I'm going to see massive breakage today :-( 09/01/10 0:43:53 is libsamba-util shipped with ldb? 09/01/10 0:44:56 I have bundled libraries off, if that answers the question. 09/01/10 0:45:33 ah, crap. libsamba-util probably doesn't get built till later. 09/01/10 0:45:41 during the real samba build. 09/01/10 0:47:08 I might have to ask for a revert... 09/01/10 0:49:31 i supose ldb cannot depend on libsamba-util? 09/01/10 0:50:27 I think the test code probably could, but I'm not sure how to structure the build to fix that. 09/01/10 0:50:39 I doubt the real library can depend on libsamba-util. 09/01/10 0:57:10 jelmer (~jelmer@samba/team/jelmer) has joined channel #samba-technical 09/01/10 1:02:06 Signoff: bradh (Remote host closed the connection) 09/01/10 1:08:43 bradh (~bradh@ppp115-205.static.internode.on.net) has joined channel #samba-technical 09/01/10 1:18:28 xaoslaad (~xaoslaad@c-66-31-144-96.hsd1.ma.comcast.net) has joined channel #samba-technical 09/01/10 1:24:12 abartlet (~abartlet@fn.samba.org) has joined channel #samba-technical 09/01/10 1:24:13 Mode change "+o abartlet" on channel #samba-technical by ChanServ 09/01/10 1:24:29 'morning all 09/01/10 1:24:52 abartlet: hi 09/01/10 1:25:07 morning abartlet 09/01/10 1:35:41 Signoff: bradh (Remote host closed the connection) 09/01/10 1:39:24 ita is now known as itazzz 09/01/10 1:39:42 ddiss (~diss@120.158.161.175) has joined channel #samba-technical 09/01/10 2:07:02 bradh (~bradh@202.124.74.236) has joined channel #samba-technical 09/01/10 2:28:51 Signoff: |Kellan| (Quit: Leaving) 09/01/10 2:57:38 Signoff: kukks (Quit: Going home ...) 09/01/10 3:02:40 BaT (~timur@dzokonda.xs4all.nl) has joined channel #samba-technical 09/01/10 3:14:29 tridge, I am testing the NBT resolve problem with nbt:timeout=2 now (again) 09/01/10 3:14:39 tridge, and it seems it is a little better 09/01/10 3:14:48 tridge, will try with nbt:timeout=3 09/01/10 3:16:00 tridge, there is one thing that puzzles me though is that we have few calls to nmblookup that are successful 09/01/10 3:16:39 tridge, those calls are executed just before running the tests, that are failing due to name resolution failure 09/01/10 3:17:11 tridge, and I can't figure out why this happens 09/01/10 3:18:15 kamenim: maybe the nbt server hasn't started yet? 09/01/10 3:18:48 tridge, it should be started as previous calls to nmblookup are successful 09/01/10 3:20:14 tridge, the only thing that I can think of is that we have 2 scheduled replications just before starting to execute the tests 09/01/10 3:20:58 tridge, this may slow down the server a little bit I guess, as we are running in single process mode right? 09/01/10 3:21:40 tridge, but event we have replications running, 2 seconds should be enought for nbt server to get a chance to respond 09/01/10 3:22:50 hmm, i should really get back to the work I was doing to run make test in standard process model 09/01/10 3:23:03 that would solve this probably 09/01/10 3:23:39 ... and make debugging horrible :) 09/01/10 3:24:14 it would be an option, like now, but the default would be for 'make test' to be multi-process 09/01/10 3:25:33 oh, it is option already 09/01/10 3:26:07 yes, but 'make test' in standard mode is not really robust yet 09/01/10 3:26:08 we can pass desired model in SAMBA_PROCESS_MODEL env 09/01/10 3:26:25 ah, I see 09/01/10 3:26:35 the problem is the killing off of child processes reliably 09/01/10 3:26:43 and we use more memory 09/01/10 3:28:06 if killing childs is problematic, then I should get all tests to pass at least right? 09/01/10 3:28:18 maybe :-) 09/01/10 3:28:28 its been a while since I've run it in that mode :) 09/01/10 3:28:33 tridge: sounds like you should use threads :-) 09/01/10 3:28:38 * bradh ducks. 09/01/10 3:28:42 :) 09/01/10 3:29:11 are there any plans for multi-threading support really? 09/01/10 3:29:38 its in the process model.... 09/01/10 3:29:40 altough it seems to me we will have a lot of issues in multi threaded environment :) 09/01/10 3:30:10 kamenim: its not completely ruled out, but its unlikely we'll do it soon, mostly because it would be very painful, and wouldn't gain much 09/01/10 3:30:28 (and may make some things slower, eg file serving) 09/01/10 3:31:46 from what I saw we shold be fine with muti-process model (althoug I have no experience with multi-process models) 09/01/10 3:32:24 what about LDAP server in this case? It is running now in single process as far as I can understood. 09/01/10 3:33:39 yep 09/01/10 3:33:47 that greatly simplified the code 09/01/10 3:34:19 but each DRS replication would get its own process 09/01/10 3:35:02 tridge: waf question - ldbtest broke over a need to get at stuff that appears to be in the LIBSAMBA-UTIL subsystem. 09/01/10 3:35:32 ahh, what bit of LIBSAMBA-UTIL is needed? 09/01/10 3:35:48 the time stuff that bj started to use 09/01/10 3:36:03 time.c 09/01/10 3:36:14 I thought of a few options 09/01/10 3:36:29 we have 4 time.c files, which one? 09/01/10 3:36:29 It is worth building libsamba-util standalone first? 09/01/10 3:36:37 lib/util/time.c 09/01/10 3:37:01 and which bit of ldbtest uses that? 09/01/10 3:37:42 http://git.samba.org/?p=samba.git;a=commitdiff;h=60002600b86808551df0fb9b907869590b670450 09/01/10 3:38:50 that function was introduced here 09/01/10 3:38:52 that patch should just be reverted I think 09/01/10 3:38:54 http://git.samba.org/?p=samba.git;a=commitdiff;h=c091b3344badac6241b85c6cf2f7dacb0f06047c 09/01/10 3:39:07 "not worth the complexity"? 09/01/10 3:39:13 indeed 09/01/10 3:39:52 tridge: thanks. will chase bj later 09/01/10 3:39:57 thanks 09/01/10 3:41:47 tridge, last question :) -> ldb transactions are synchronized on the disk right? So it should be feasible to fork a new process for every LDAP connection, DRS replication, etc, right? 09/01/10 3:42:33 in principle, yes, but in practice its not so simple. The ldap server keeps some of its state in memory 09/01/10 3:44:41 I guess so, but at least we won't corrupt the database 09/01/10 3:45:30 oh, I got another one - what do you thing about broadcasting messages in IRPC messaging subsystem? 09/01/10 3:46:01 I mean, that right now, if I want to send a message I need to know server_id of the server to send message to 09/01/10 3:46:56 its possible, but can be very expensive. Imagine we have 2000 SMB server connections open 09/01/10 3:47:08 then every one would need to wake up and respond 09/01/10 3:47:18 multi-casting to groups would make more sense 09/01/10 3:49:03 yes, you are right, but that are the risks when using observer pattern 09/01/10 3:50:25 thanks a lot tridge 09/01/10 3:52:11 good night (day actually) 09/01/10 3:52:17 night! 09/01/10 3:52:20 Signoff: ohsix (Read error: Operation timed out) 09/01/10 3:52:25 ohsix (ohsix@66.220.111.99) has joined channel #samba-technical 09/01/10 4:25:52 Signoff: bradh (Remote host closed the connection) 09/01/10 4:35:02 Signoff: mavrick61 (Remote host closed the connection) 09/01/10 4:36:12 mavrick61 (~mavrick61@213.132.111.1) has joined channel #samba-technical 09/01/10 6:37:18 Signoff: xaoslaad (Quit: Leaving) 09/01/10 6:38:27 jays (~jay@nat/novell/x-pdvuxkpppkhngqsz) has joined channel #samba-technical 09/01/10 6:48:25 Signoff: shen-long (Read error: Connection reset by peer) 09/01/10 6:48:37 coffeedude (~CoffeDude@209.116.48.3) has joined channel #samba-technical 09/01/10 6:49:14 shen-long (~shen-long@97.73.173.213) has joined channel #samba-technical 09/01/10 7:48:59 bradh (~bradh@ppp115-205.static.internode.on.net) has joined channel #samba-technical 09/01/10 8:11:29 hi * 09/01/10 8:11:39 abartlet: still here by chance ? 09/01/10 8:12:30 yes, I'm around 09/01/10 8:13:20 abartlet: great, maybe you saw emails of trever on the list about gpo pb between vista and s4 ? 09/01/10 8:13:30 yeah, I saw the mails 09/01/10 8:13:54 I had hoped you had it all in hand, but I can look at the problem if you like 09/01/10 8:14:06 so he send me a trace and in the trace I have access denied on the file 09/01/10 8:15:39 what bugs me is that in wireshark he has a ntlm session and setup associated to tree 65535 09/01/10 8:15:58 and with this tree id vista open \\domain\IPC$ 09/01/10 8:18:17 but not with the treeid for \\domain\sysvol 09/01/10 8:21:30 abartlet: how from tcpdump can I understand to which session setup and request a tree connect is related ? 09/01/10 8:24:33 ekacnet: the VUID will be the same in both packets 09/01/10 8:25:45 argg there is no attribute like this in wireshark :-) 09/01/10 8:25:54 user id maybe it is ? 09/01/10 8:27:09 yep 09/01/10 8:27:25 then it's not the pb :-) 09/01/10 8:27:37 well hope for the s4 logs to tell me more 09/01/10 8:32:03 Signoff: d43mOn (Quit: Leaving.) 09/01/10 8:48:10 Signoff: coffeedude (Quit: Ex-Chat) 09/01/10 9:08:15 metze: ping 09/01/10 9:12:16 kinkie (~kinkie-ir@eu.squid-cache.org) has joined channel #samba-technical 09/01/10 9:16:03 redder86: pong 09/01/10 9:16:40 metze: hi, thank you for all of your help so far. I have identified the code which is causing this problem: 09/01/10 9:17:13 Compiling ../librpc/idl/ms-fax.idl 09/01/10 9:17:13 Unknown scalar type at /usr/src/samba/pidl/lib/Parse/Pidl/Typelist.pm line 96. 09/01/10 9:17:13 make: *** [samba3-idl] Error 1 09/01/10 9:17:40 typedef 09/01/10 9:17:40 [switch_type(int)] 09/01/10 9:17:40 union { 09/01/10 9:17:40 [case(0)] 09/01/10 9:17:40 DWORD dwDeviceId; 09/01/10 9:17:40 [default] 09/01/10 9:17:41 [string] [string] LPWSTR lpwstrGroupName; 09/01/10 9:17:41 } FAX_RULE_DESTINATION; 09/01/10 9:17:52 typedef struct { 09/01/10 9:17:52 DWORD dwSizeOfStruct; 09/01/10 9:17:52 DWORD dwAreaCode; 09/01/10 9:17:52 DWORD dwCountryCode; 09/01/10 9:17:52 [string] LPWSTR lpwstrCountryName; 09/01/10 9:17:53 [switch_is(bUseGroup)] FAX_RULE_DESTINATION Destination; 09/01/10 9:17:53 BOOL bUseGroup; 09/01/10 9:17:54 FAX_ENUM_RULE_STATUS Status; 09/01/10 9:17:54 } FAX_OUTBOUND_ROUTING_RULEW; 09/01/10 9:18:21 The problem is with the [switch_is(bUseGroup)] line. If I remove this line then I do not get the error. 09/01/10 9:18:56 This code comes from Microsoft MSDN. How can this be fixed? 09/01/10 9:19:25 how did you define BOOL? 09/01/10 9:19:42 #define BOOL int 09/01/10 9:22:41 http://gateway.howardsilvan.com/ms-fax.idl 09/01/10 9:25:17 define it to uint32 09/01/10 9:25:28 int isn't a known type 09/01/10 9:25:39 as it doesn't have a fixed size 09/01/10 9:25:56 changed to uint32, but I get the same thing... 09/01/10 9:25:56 Compiling ../librpc/idl/ms-fax.idl 09/01/10 9:25:56 Unknown scalar type at /usr/src/samba/pidl/lib/Parse/Pidl/Typelist.pm line 96. 09/01/10 9:25:56 make: *** [samba3-idl] Error 1 09/01/10 9:26:07 switch_type(int) 09/01/10 9:26:12 => switch_type(BOOL) 09/01/10 9:26:18 oh, there 09/01/10 9:26:25 in both places 09/01/10 9:27:14 that works, fantastic, thanks. 09/01/10 9:27:55 alternatively I can just do this, too.... #define int uint32 09/01/10 9:28:28 I assume that I can safely ignore these warnings, right? warning: Unable to convert uint32 to NTSTATUS 09/01/10 9:31:55 sadly yes 09/01/10 9:32:30 thank you again 09/01/10 9:32:34 you've been very gracious 09/01/10 9:32:47 but it means you won't get the errors 09/01/10 9:33:27 for master you can use the dcerpc_*() functions 09/01/10 9:33:36 which have that fixed 09/01/10 9:33:55 but if you want to backport to older samba 3 releases 09/01/10 9:34:08 you have to use the rpccli_*() functions 09/01/10 9:34:34 which will hide and ignore the application level return value 09/01/10 9:35:37 I'll be using master. 09/01/10 9:37:11 originally I had wanted to use 3.2.4, but there are too many fixes to backport from master. 09/01/10 9:37:42 it will be easier for me to switch to master 09/01/10 9:44:00 Signoff: sahlber1 (Remote host closed the connection) 09/01/10 9:44:28 sahlberg (~ronnie@CPE-144-131-126-72.lns5.cht.bigpond.net.au) has joined channel #samba-technical 09/01/10 9:55:50 Signoff: bradh (Remote host closed the connection) 09/01/10 10:00:52 itazzz is now known as ita 09/01/10 10:06:05 Signoff: ddiss (Remote host closed the connection) 09/01/10 10:22:51 aatanasov (~Anatoliy@78.90.6.91) has joined channel #samba-technical 09/01/10 10:41:04 morning folks 09/01/10 10:47:04 Signoff: abartlet (Quit: Leaving.) 09/01/10 11:30:33 ambi_ (~ambi@nat/ibm/x-simjkgozyfuxmpeg) has joined channel #samba-technical 09/01/10 11:51:08 Signoff: jays (Ping timeout: 258 seconds) 09/01/10 12:06:08 bradh (~bradh@ppp115-205.static.internode.on.net) has joined channel #samba-technical 09/01/10 12:07:17 jays (~jay@nat/novell/x-ixjntkiydckcfqyd) has joined channel #samba-technical 09/01/10 12:35:35 Signoff: sahlberg (Quit: Leaving.) 09/01/10 12:35:53 sahlberg (~ronnie@CPE-144-131-126-72.lns5.cht.bigpond.net.au) has joined channel #samba-technical 09/01/10 12:45:11 Signoff: jays (Ping timeout: 258 seconds) 09/01/10 12:55:04 Signoff: ita (Ping timeout: 252 seconds) 09/01/10 12:55:38 ita (~ita@kde/developer/tnagy) has joined channel #samba-technical 09/01/10 12:56:47 jays (~jay@nat/novell/x-sybfottwvtkbnsrx) has joined channel #samba-technical 09/01/10 13:23:44 Signoff: ita (Ping timeout: 265 seconds) 09/01/10 13:24:56 ita (~ita@kde/developer/tnagy) has joined channel #samba-technical 09/01/10 13:40:01 Signoff: ivan` (Quit: Coyote finally caught me) 09/01/10 13:40:10 ivan` (~ivan@unaffiliated/ivan/x-000001) has joined channel #samba-technical 09/01/10 13:44:32 Signoff: bradh (Remote host closed the connection) 09/01/10 13:45:22 mimir (~rafal__@static-87-105-185-84.ssp.dialog.net.pl) has joined channel #samba-technical 09/01/10 14:32:31 Signoff: jays (Ping timeout: 258 seconds) 09/01/10 14:51:19 Signoff: ita (Read error: Connection reset by peer) 09/01/10 15:01:08 Signoff: aatanasov (Quit: Leaving) 09/01/10 15:25:37 Signoff: JaixBly (Quit: Jaix Bly Växjö, Sweden, Skriv fel: Per återställde kopplingen. - Vem är den där Per egentligen? -Det var han som dödade Neo) 09/01/10 15:43:42 kukks (~Guenter@p57A08B54.dip0.t-ipconnect.de) has joined channel #samba-technical 09/01/10 16:04:19 xaoslaad (~xaoslaad@c-66-31-144-96.hsd1.ma.comcast.net) has joined channel #samba-technical 09/01/10 16:14:05 Signoff: blingme (Ping timeout: 276 seconds) 09/01/10 16:19:09 blingme (~quassel@mandriva/channel-support/ranger) has joined channel #samba-technical 09/01/10 16:24:55 Signoff: ambi_ (Quit: Leaving.) 09/01/10 16:50:20 Signoff: blingme (Ping timeout: 276 seconds) 09/01/10 16:52:08 blingme (~quassel@82.128.40.14) has joined channel #samba-technical 09/01/10 16:52:08 Signoff: blingme (Changing host) 09/01/10 16:52:08 blingme (~quassel@mandriva/channel-support/ranger) has joined channel #samba-technical 09/01/10 17:02:01 blingme_ (~quassel@82.128.40.14) has joined channel #samba-technical 09/01/10 17:02:41 Signoff: blingme (Ping timeout: 276 seconds) 09/01/10 17:44:15 ab is now known as ab[out] 09/01/10 17:49:10 Signoff: jelmer (Quit: Ex-Chat) 09/01/10 17:57:06 Signoff: rektide (Ping timeout: 240 seconds) 09/01/10 17:57:45 jelmer (~jelmer@samba/team/jelmer) has joined channel #samba-technical 09/01/10 18:05:03 lagarcia (~lagarcia@32.59.1.230) has joined channel #samba-technical 09/01/10 18:09:30 Signoff: kinkie (Quit: $HOME, sweet $HOME) 09/01/10 18:29:48 Signoff: lagarcia (Quit: Leaving) 09/01/10 19:38:54 in idl, what data type can I use for a 64-bit integer? 09/01/10 19:39:00 there is no uint64 09/01/10 19:42:06 dunno, but have you tried virtual or long long? 09/01/10 19:52:23 d43mOn (~sysadmin@190.229.176.13) has joined channel #samba-technical 09/01/10 19:55:55 Signoff: jelmer (Quit: Ex-Chat) 09/01/10 20:12:04 redder86: hyper 09/01/10 20:12:26 vl: thanks 09/01/10 20:15:57 argh, meant to say hyper, not virtual... sorry 09/01/10 20:18:50 Signoff: mimir (Remote host closed the connection) 09/01/10 20:34:04 trever is here by chance ? 09/01/10 20:34:09 hi * btw 09/01/10 20:35:57 Signoff: xaoslaad (Quit: Leaving) 09/01/10 20:42:04 jelmer (~jelmer@samba/team/jelmer) has joined channel #samba-technical 09/01/10 20:44:22 cworth has left channel #samba-technical because ("Leaving") 09/01/10 20:47:42 in smb in a create andx request if you do not specify the share_write flag does it means that you must have the write right on the folder ? 09/01/10 20:47:49 or the file 09/01/10 21:08:18 vl: ping ? 09/01/10 21:19:22 ekacnet: pong 09/01/10 21:29:28 vl: did you see my question just above ? 09/01/10 21:31:42 mimir (~rafal__@static-87-105-185-84.ssp.dialog.net.pl) has joined channel #samba-technical 09/01/10 21:32:30 ekacnet: No, they are independent. 09/01/10 21:33:01 A second open with request for write conflicts with an existing !FILE_SHARE_WRITE 09/01/10 21:51:19 Signoff: shen-long (Read error: Connection reset by peer) 09/01/10 21:59:10 shen-long (~shen-long@97.73.173.213) has joined channel #samba-technical 09/01/10 22:11:07 Signoff: knewt2 (Ping timeout: 240 seconds) 09/01/10 22:12:05 knewt2 (jmb@home.pimb.org) has joined channel #samba-technical 09/01/10 22:18:51 vl: ah ok thank you 09/01/10 22:19:29 I'm just trying to figure out why on the same file with vista I get access denied on create andx request when xp is ok 09/01/10 22:19:37 and I saw the difference in the falgs 09/01/10 22:19:41 flags 09/01/10 22:21:38 Signoff: kamenim (Ping timeout: 264 seconds) 09/01/10 22:24:51 kamenim (~kamenim@85-130-9-214.2073153801.ddns.cablebg.net) has joined channel #samba-technical 09/01/10 22:29:43 Signoff: d43mOn (Ping timeout: 245 seconds) 09/01/10 22:30:50 d43mOn (~sysadmin@186.108.183.14) has joined channel #samba-technical 09/01/10 22:45:04 ita (~ita@kde/developer/tnagy) has joined channel #samba-technical 09/01/10 22:45:21 * ita *miau* 09/01/10 22:52:31 ekacnet: access denied is different. 09/01/10 22:52:47 a conflict with the flags would be NT_STATUS_SHARING_VIOLATION 09/01/10 23:28:04 bradh (~bradh@ppp115-205.static.internode.on.net) has joined channel #samba-technical 09/01/10 23:28:32 vl: thks 09/01/10 23:34:01 tridge, ping 09/01/10 23:35:02 kamenim: hi 09/01/10 23:36:13 tridge, oups, you surprised me - I tought you not here yet :) 09/01/10 23:36:49 tridge, I think I found another quite possible reason for failing vampire_dc tests 09/01/10 23:37:03 kamenim: oh? 09/01/10 23:37:06 tridge, and it seems it is the... RID Manager implementation 09/01/10 23:37:37 whats going wrong with it? 09/01/10 23:37:48 Signoff: dmarkey (Ping timeout: 240 seconds) 09/01/10 23:37:56 dmarkey (~dmarkey@dmarkey.xen.prgmr.com) has joined channel #samba-technical 09/01/10 23:38:11 tridge, the efect I am observing after incresing timeout for nbt server is that we start to fail IRPC requests to DsReplicaSync 09/01/10 23:38:59 tridge, I've bumped the timeout for IRPC to 60 secs 09/01/10 23:39:44 something is pretty badly wrong if it takes more than the current limit of 10s 09/01/10 23:40:03 tridge, oh, sorry, before bumping the IRPC timeout, what happens is that IRPC requests have timed out 09/01/10 23:40:03 kamenim: did changing the limit help? 09/01/10 23:41:20 tridge, I've bumped logging level for vampired DC just to find out that right after it requests another RID pool, the PDC jsut returned us the whole DefaultNamingContext (and in the end of 'make test' we have a *lot* of objects there) 09/01/10 23:41:49 tridge, so basically vampired dc gets stucked for log time to try apply the result from GetNCChanges 09/01/10 23:42:19 ahh, ok 09/01/10 23:42:27 when I bump the IRPC timeout to 60 seconds everything was fine, except that vampired DC never manage to get requested RID pool :) 09/01/10 23:42:30 why does it return the whole NC ? 09/01/10 23:43:03 so almost all tests succeeded execept the last one - it is creating a lot of users and groups and vampired DC just run out of RIDs 09/01/10 23:43:04 hmm, actually, I think I know why 09/01/10 23:43:21 its a bug in our getncchanges server code I think 09/01/10 23:43:28 yes - there is no special handling for RID Requests in GetNCChanges - we just return everything 09/01/10 23:43:45 well, there is special handling, its the rewrite of the DN 09/01/10 23:44:03 the RID manager getncchanges request happens on the RID Manager$ DN 09/01/10 23:44:25 but we rewrite the DN to be the whole NC, as it i supposed to include side-effects of the rid allocation in the response 09/01/10 23:44:48 so I think what we need to do is this: 09/01/10 23:45:05 1) when we get a RID Manager$ request, note the current hightest uSN on the NC 09/01/10 23:45:19 2) then do the RID pool allocation 09/01/10 23:45:23 what I understand from MS docs is that we need to return just several objects - 09/01/10 23:45:27 ita is now known as itazzz 09/01/10 23:45:41 3) then in the search, use a lowwater mark equal to what the highest uSN was before the allocation 09/01/10 23:46:07 yes, but knowing exactly what objects is hard, with the above method we'll always get the right ones (if we use a transaction) 09/01/10 23:46:20 if you like, we can fix this together now 09/01/10 23:46:23 there is nothing about 1) and 3) in MS description (perhaps a faulty rreading on my side but still) 09/01/10 23:46:40 kamenim: thats because its an implementation detail - its not really part of the docs 09/01/10 23:46:48 the MS docs don't mention ldb either :-) 09/01/10 23:47:02 :) not a good argument :)