On 03/06/2014 03:13 PM, David C. Rankin wrote:
> On 03/06/2014 12:14 AM, François Andriot wrote:
>> Le 06/03/2014 06:45, David C. Rankin a écrit :
>>> On 03/03/2014 02:06 PM, François Andriot wrote:
>>>> [...]
>>> Francois,
>>>
>>>    I'll say it again, "you're good!"
>>>
>>>    Is the slave in #7 actually sending the "finished" and it never makes it to
>>> the job? Or is it not sending "finished" at all?
>>>
>>>    Is there any possibility that #7 does not occur because the slave does not
>>> know where to send "finished"? What links/connects the slave to the job? Is it a
>>> signal/slot, or some memory address that the job originally passed to the slave
>>> in #3? Or does the slave just generate the "finished" and pass some type of job
>>> number along with it after #6??
>>>
>>>    Could the slave/job connection created in #3 be broken somehow such that the
>>> reverse path in #7 no longer exits after the delay in #6?
>>>
>>
>>
>> Please check bug report #1902 : I've posted 2 patches there.
>> If it's confirmed working, I'll explain what I believe is the root cause of this
>> problem.
>>
>> Francois
>>
> 
> Whoop!
> 
>   After patch and rebuild of tdebase and tdelibs with the patches, I no longer
> have any stale tdeio_sftp processes hanging around (details posted to bug 1902).
> Will continue to test, but it is looking good.
> 
>   XDG_SESSION_ID still does not show proper user session tracking :(
> 

It looks like the fix was:

tdelibs/tdeio/tdeio/kdirlister.cpp - line 1974:

  job->slaveDone();

That would explain why #7 never got done.

-- 
David C. Rankin, J.D.,P.E.