Well, the appropriate way to report a bug is to [EMAIL PROTECTED]
The contents of the bug report vary depending on what it is that you are attempting to report. If it is a crash, then useful information consists of:
* the %WINDIR%\TEMP\afsd_init.log
* the %WINDIR%\TEMP\afsd.log
* a stack trace if you were able to get one
* a minidump if you were able to get one
* An ability to replicate the problem. Replication is 95% of the work associated with fixing a bug. Most (but not all) crash bugs are something small and stupid not major design problems
If it is not a crash report, then again replication is 95% of the work. Spend the time to isolate the problem as much as possible so that you can easily explain how I can replicate it. If possible provide me remote access to a machine suffering the problem with Debugging Tools for Windows installed and the necessary cell access to reproduce the symptoms in the debugger.
OpenAFS for Windows does have the ability to generate trace logs but they are most useful after a general idea of where the problem is and new debugging statements have been added to focus explicitly on that problem. This is a last resort when access to the machine and a debugger cannot be obtained.
As for the bug you describe below, the Windows SMB/CIFS client uses a variable length timeout based upon the server being accessed. In the case of OpenAFS, the entire AFS name space is treated as one server, "AFS", by the Windows time out. If the experience of Windows is that it takes a long time to obtain a response, then it will wait a long time before timing out. The AFS RPC timeout period is about two minutes. The SysInternals FileMon.exe tool is very useful for watching the behavior of Windows as a SMB/CIFS client. Simply turn off capturing for all local devices and you will see only the SMB/CIFS accesses.
Jeffrey Altman
James Burns wrote:
Jeffrey, Just to clarify, I was being purposefully vague because I was looking for general information on bug reporting rather than actually trying to report one. I did figure out some more information on this so-called hanging, but I'm not sure if it's an AFS bug or a Microsoft one. I found out that my cell (1.2.11 on Linux) was in some sort of hung state. Attempts to access it via the Linux client returned immediate connection timeout errors. In Windows however, attempting to access the cell hung Explorer, apparently indefinitely. Sometimes bringing up a My Computer view would hang it, sometimes trying to open a mapped drive would as well. In one instance stopping the service and restarting it worked (this was before I understood the issue though, so I'm not as sure of the details). I didn't know the command line to do the restart so I ended up killing Explorer a few times before I realized that I needed to restart my cell (it's a "home" one server cell). I'll see if I can get my cell hung again (it seems to be happening when I move large files around) and perhaps send you connection information so you can see if it happens to you. The hanging was happening when I was accessing it over the Internet as well as locally so there's a fair chance you'll see it. I'll send a bug report after another iteration of trying to get more information.
-James
smime.p7s
Description: S/MIME Cryptographic Signature
