Assume for a moment (and yes, I DO know what happens when you assume
something , that at a given point in my Windows application that I try to
use a socket and it tells me that it is "busy" and I KNOW, without a shadow
of a doubt that it is NOT "busy". Is there a way to make this socket
"unbusy" without rebooting the machine?

Same thing for a file. Application crashes or whatever, and a filestream
never releases, is there a way to "unbusy" the file without rebooting?

We are actually running into both of these problems and are trying to figure
out how to gracefully recover from these problems.

TIA

WhiteWizard
aka Gandalf
MCSD.NET, MCAD, MCT

If you close the connection from one side it should inform the other
side and close it as well. I do not know if this will work for a busy
Socket or not, but try calling

<socketName>.Close()

and have code on your other end that when the socket is closed it
starts the process of reconnecting.

WhiteWizard wrote:
> Assume for a moment (and yes, I DO know what happens when you assume
> something , that at a given point in my Windows application that I try to
> use a socket and it tells me that it is "busy" and I KNOW, without a shadow
> of a doubt that it is NOT "busy". Is there a way to make this socket
> "unbusy" without rebooting the machine?
>
> Same thing for a file. Application crashes or whatever, and a filestream
> never releases, is there a way to "unbusy" the file without rebooting?
>
> We are actually running into both of these problems and are trying to figure
> out how to gracefully recover from these problems.
>
> TIA
>
> WhiteWizard
> aka Gandalf
> MCSD.NET, MCAD, MCT

> Same thing for a file. Application crashes or whatever, and a filestream
> never releases, is there a way to "unbusy" the file without rebooting?

Can you give a short but complete example of a process that opens a file ...
the process terminates and yet the file stays open?

When the app terminates the handle is automatically closed (or should be)

This shouldn't happen ..

Cheers,

Greg
"WhiteWizard" <(E-Mail Removed)> wrote in message
news:50A8A5E0-1B61-4CAA-8B25-(E-Mail Removed)...
> Assume for a moment (and yes, I DO know what happens when you assume
> something , that at a given point in my Windows application that I try
> to
> use a socket and it tells me that it is "busy" and I KNOW, without a
> shadow
> of a doubt that it is NOT "busy". Is there a way to make this socket
> "unbusy" without rebooting the machine?
>
> Same thing for a file. Application crashes or whatever, and a filestream
> never releases, is there a way to "unbusy" the file without rebooting?
>
> We are actually running into both of these problems and are trying to
> figure
> out how to gracefully recover from these problems.
>
> TIA
>
> WhiteWizard
> aka Gandalf
> MCSD.NET, MCAD, MCT

"WhiteWizard" <(E-Mail Removed)> wrote
> Is there a way to make this socket
> "unbusy" without rebooting the machine?

Terminating the process that owns the socket will kill the socket.

The magic tool for sockets is "netstat", and it's part of the standard
Windows Install. This will show you all sockets (-a), their state, and the
process that owns the socket (-o).

> Same thing for a file. Application crashes or whatever, and a filestream
> never releases, is there a way to "unbusy" the file without rebooting?

Same answer as for a socket. Kill the owning process.To find out which
process owns a file, you need to hit the SysInternals web page and download
one of their tools (FileMon?)


> We are actually running into both of these problems and are trying to
> figure
> out how to gracefully recover from these problems.

I suspect your problems is really something else - I do ALOT of socket and
file work and almost never come across these issues unless it's due to a
mistake on my end. Can you post some sample code?

--
Chris Mullins, MCSD.Net, MCPD:Enterprise
http://www.coversant.net/blogs/cmullins