Not really, I am still getting all sorts of grief. A partial workaround to a lot of issues was to have Bill Richardson (of RHIT) include some special code to restart AFS service each time the token is renewed in his WAKE application (http://www.rose-hulman.edu/TSC/software/wake/ - which I think anyone running AFS for windows should have, especially if they want to integrate authentication between Win2k and AFS) It's a somewhat hidden option in the registry, but it really saves a lot of grief.
Generally speaking I find Windows openAFS 1.2.2b somewhat lacking the stability to be used in the production environment (at least for running on Win2K) . Every machine I loaded it onto almost immediately started exibiting erratic behaviour. In many cases I had to switch AFS service to manual startup and let WAKE start it up on load. This stopped most of the boot-time problems -- in "Automatic" startup mode, 1.2.2b had about 1 in 3 failure rate on statartup. But that still leaves some problems. Occasionally AFS will not get restarted by WAKE , at that point the only way to get AFS working is reboot. But the biggest issue is that when AFS is running it still dows something strange to memory, because I have all sorts of applications crash with the message like this (comming from different applications): MSTask.exe - Application Error : The instruction at "0x77fcb03d" referenced memory at "0x00000000". The memory could not be "written". This seems to me that Which seems to me like maybe some buffer overflow problems exist in the client which would account for memory leakage and possibly other application crahes (if windows indeed does allow one application to get into memory space of another, which would not surprise me at all) All in all, given these issues and given that I do not believe anyone is really supporting or cares for Windows client(most of the questions about Windows client to this list seem to go unanswered, at least publically) I decided to hold off on deploying windows part of the AFS here indefinately. At some point I am going to check cout the latest code from CVS and play with it, but right now I simply do not have the time for that. And to add to that id does not appear that anyone really maintaines or cares much for the windows clients. I have to add some disclaimers to this, all of the tests I've done were done on identically configured machines, with pretty much same software set including DB2 client and DB2Connect, which some people on this list though DB2 stuff may cause problems for openAFS (not sure why and it was never confirmed or denied) Also, I've only tried using openAFS client on windows, not server. -michael ----- Original Message ----- From: "Christian Boissat" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 22, 2002 2:52 AM Subject: OpenAFS-devel] Windows client - memory leak? > Michael and All, > > At CERN, for some openAFS end-users, we have the same behaviour as the one > described in : > > https://lists.openafs.org/pipermail/openafs-devel/2002-May/002936.html > > To your knowledge, has the problem being identified. Is there any fix in > preparation ? > > Cheers; Christian Boissat > > _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
