On 03/23/98 10:28:58 you wrote:

When I've got a bug that's affecting my customers and the quality of service I'm offering, I could care less if its been "sanitized" and internal engineering comments / cuss words / etc has been removed - I want the *info available*, or at least indication that the problem *is* an acknowledged bug and NetApp is working on it, as *soon as possible*.

Not to be an apologist for Netapp, but I have seen other reasons offered from time to time. For example, internal bug reports can contain portions of source code or other proprietary facts about the internal workings of the filer, bugs that are mischaracterized (which could mislead the unsuspecting customer into thinking it is something else), or even disagreements between engineers over the nature of the bug involved. I think these sorts of things should be filtered. Furthermore, some bugs get discovered in internal testing that do not get immediately fixed at release. Someone would have to, at release, identify these bugs that still exist and move them into the "public", as it were.

NetApp, if you're going to keep a list of bugs on your web page, make sure they're up-to-date, otherwise such info is useless. I've made this request at least twice, and never heard anything of it.

I agree. I'm sure Netapp agrees as well. Putting the manpower and expertise together to do that, however, is not as easy as it may seem on a first pass.

The other "minor annoying" problem I've seen with the Toasters:

nfs> exit Use control-D to exit nfs> ^D Connection closed by foreign host.

Why not just use the code that is in the OS to print "Use control-D to exit" to make the filer go ahead and exit?

I got an answer to this when I first asked it during the 1.x days. :) You may have noticed by now that the filer doesn't really support multiple tty sessions. If you're on the console and someone else telnets in, you're really multiplexed off the same character stream. So when the command parser gets an "exit", it doesn't know which connection(s) it came from. The control-D, on the other hand, is caught higher up in the input driver.

I suppose one could check to see if there is only one session. Or there may be a way to put together some code to determine where the command came from. But the real fix would be to support multiple concurrent sessions. With the emphasis on GUI and rsh and such in more recent releases, that feature may not even be on the roadmap anymore. Or, maybe it's in 5.x?

Bruce