Mike:
I can verify that there is a problem although I cannot determine
at the moment what the source of it is. What is the most recent
version of KFW that you are aware works?
Please send a bug report to [EMAIL PROTECTED]
Jeffrey Altman
Mike Friedman wrote:
> I posted on this a few days ago
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I posted on this a few days ago but haven't received any replies, so I
figure it may have fallen through the cracks.
It seems that with the current release of KfW, password changing fails to
either a 1.3.4 or 1.4.2 KDC. Yet, earlier versions of K
Yes, I think allocating the storage and initializing it at most once
per context, delayed until the actual resolver usage, is the right
way to deal with this. Simply adding a pointer field to the context,
initialized to NULL, is probably the way to start
Ken
___
> "brian" == brian joh <[EMAIL PROTECTED]> writes:
brian> Ken Raeburn wrote:
>> We've run into other cases where a krb5_context is needed but
>> other APIs make it difficult for one to be made available. So
>> there's code out there that allocates many short-lived
>> krb5
I can replicate the problem but don't see anything obviously wrong.
Please send a bug report to [EMAIL PROTECTED]
Jeffrey Altman
Hughes, Noah L [ECSS] wrote:
> Jeffrey,
>
> You are right, kdestroy.exe works with the FILE:c:\temp\krbcache. The
> reason I had trouble was that the destroy functi
Jeffrey,
You are right, kdestroy.exe works with the FILE:c:\temp\krbcache. The
reason I had trouble was that the destroy function in Leash32 locked the
file and went into the 99% CPU usage.
The kdestroy.exe error was from Leash32 locking the file.
It appears that Leash32 is the program that ha
