I am taking about the change #1297-1301

With regards,
Samarjit


On Mon, Feb 25, 2013 at 10:31 AM, samarjit Adhikari <
samarjit.adhik...@gmail.com> 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 <
> samarjit.adhik...@gmail.com> 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 <mc...@redhat.com> 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
>>> evolution-hackers@gnome.org
>>> To change your list options or unsubscribe, visit ...
>>> https://mail.gnome.org/mailman/listinfo/evolution-hackers
>>>
>>
>>
>
_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to