I'm making some utils that uses NetUseAdd and NetUseDel functions to connect/disconnect to share. In Windows 7 I noticed that between calling NetUseDel and real disconnnection passes nearly 12 seconds.
I made some investigations and found that net use \server /del also disonnects only after 12 seconds. Here's little script and Wireshark output, corresponding to run of script:
net use \\server "" /user:""
net use \\server /delete
http://i.stack.imgur.com/5CyCw.png
Setting last tree connect smb command as reference, we can see, that tree disconnect delayed for 12 seconds.
Does anyone know how to cut such a timeout?
The connecion can stay alive sometimes even more than 12 seconds.
The trick is to force a bad login after deletion.
If you force a bad login then the share will be inaccessible immediately. We can use the local Guest account for that (it will usually give the error "Logon failure: account currently disabled." and even if it is enabled it will not have access).
Instead of just:
net use \\server /delete
We will execute:
net use \\server /delete
net use \\server "" /user:"Guest"
net use \\server /delete 2>nul
The third line is executed just in case the Guest login succedes (it usses 2>nul for error stream redirection to the nul device, to avoid displaying any error messages).
This is the batch version that uses the "net use" command, but the same solution can be applied when using NetUseAdd and NetUseDel from netapi32.dll, or WNetAddConnection and WNetCancelConnection from mpr.dll.
Why would you want to delay the disconnection? The whole point of the time-out is to essentially cache the share, since Windows knows that if you access a share once, you're likely to do so again. It doesn't want to waste the time of continually setting up and tearing down a connection that could easily be left open, so it delays closing it.
If you need to access the share, then this helps you. Don't worry about deleting it so that you can recreate it; just use it.
Since the SMB client kernel driver handles these request you cannot control when it will actually disconnect, the 12 seconds delay you are experiencing is actually just the time the kernel handler took to kill the underlying tcp connection. as a workaround i would use NetUseEnum to verify that the connection was actually deleted in a while loop with a counter.
you can see my answer here for more info on how to create multiple connections, short of using another smb implementation or creating a windows workstation per connection you are out of luck.
