I am taking about the change #1297-1301 With regards, Samarjit
On Mon, Feb 25, 2013 at 10:31 AM, samarjit Adhikari < [email protected]> wrote: > hi All, > > As suggested, I have open a mapi connection using camel services but got a > crash in g_rec_mutex_lock function. > Crash debugging attached. it seems the connection has not being > initialized yet. Any help?? > > My latest code changes are present in following branch. i have attached > modified files as well. > > http://bazaar.launchpad.net/~samarjit-adhikari/evolution/evolution-mapi-3.6.2/changes > > With regards, > Samarjit > > > On Fri, Feb 22, 2013 at 5:46 PM, samarjit Adhikari < > [email protected]> wrote: > >> Hi Milan >> >> >Correct way would be to provide >> >"connect_sync/authenticate_ >> >sync/disconnect_sync" for the >> >CamelMapiTransport structure, where you get everything, the password and >> >such, without dealing with evolution internals. >> >> I can not follow the sequence of camel service >> "connect_sync/authenticate_sync/disconnect_sync" as inside that function >> "mapi_authenticate_sync" >> following code is present. >> >> store->priv->connection = e_mapi_connection_new ( >> e_mail_session_get_registry (E_MAIL_SESSION >> (camel_service_get_session (service))), >> profile, password_str, cancellable, &mapi_error); >> >> Thus the pointer store->priv->connection will be overwritten during >> send_to_sync. >> >> Only way i found is using "e_mapi_connection_new". Do let me know your >> view. >> >> With regards, >> Samarjit >> >> >> On Fri, Feb 22, 2013 at 3:39 PM, Milan Crha <[email protected]> wrote: >> >>> On Fri, 2013-02-22 at 12:50 +0530, samarjit Adhikari wrote: >>> > I build it and tried to use it. IT was UNSUCCESSFUL. it was >>> > NT_STATUS_WRITE_FAULT as follows. I lost in sea. What to do next i am >>> > not sure. Any idea?? >>> >>> Hi, >>> one of the reasons to reuse already running connections is slowness with >>> which libmapi/samba connects to the server, it takes around 10 seconds >>> here, sometimes more, sometimes less. >>> >>> The NT_STATUS_WRITE_FAULT is a reason of >>> > dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED >>> which can happen when a wrong password is used, if I recall correctly, >>> and you passed no password, which causes the error most likely (unless >>> you use kerberos login). >>> >>> The way you get to registry is also not 100% correct, but I understand >>> there are not many options for this. I just mean that I'd not agree for >>> such patch in upstream. Correct way would be to provide >>> "connect_sync/authenticate_sync/disconnect_sync" for the >>> CamelMapiTransport structure, where you get everything, the password and >>> such, without dealing with evolution internals. >>> Bye, >>> Milan >>> >>> _______________________________________________ >>> evolution-hackers mailing list >>> [email protected] >>> To change your list options or unsubscribe, visit ... >>> https://mail.gnome.org/mailman/listinfo/evolution-hackers >>> >> >> >
_______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
