[jcifs] Disconnect from a share

[Michael B Allen]

On Thu, 11 Aug 2005 16:05:15 +0200
Mathias Dietz <MDIETZ at de.ibm.com> wrote:

> there is no way to make a clean disconnect from a share after doing some
> stuff .

Transports timeout and close after being idle for 15000 milliseconds.

> E.g.
> System.out.println("CONNECT TO: smb://" + ip + "/smb_control/");
> SmbFile smb =new SmbFile("smb://;:@" + ip+ "/smb_control/");
> String[] sm = smb.list();
> System.out.println("Finished !");
> //here close the SMBSession , Transport
> 
> The only way to disconnect, seems to be the socket timeout (
> jcifs.smb.client.soTimeout) but
> this generates ugly error messages on the server :
> Aug 11 15:30:17 back1 smbd[30618]:   write_socket: Error writing 43 bytes
> to socket 26: ERRNO = Broken pipe

This error should not occur with a reasonable soTimeout value. I think
you might be setting soTimeout too low.

> I would prefer a disconnect() method in SmbFile which does something like:
>    /**
>    * Disconnect from server.
>    * WARNING! Closes the SMBTransport and all active SMBSession's.
>    * Should only be called if no other SMBSession is alive or required.
>    *  @param boolean hard ,  If false close only if no active request is
>    outstanding.
>    */
>    public void disconnect(boolean hard){
>       tree.session.transport.disconnect(hard);
>    }
> 
> or a transport_idle_timeout , which makes a clean disconnect before closing
> the socket.

That's what soTimeout does. When the transport is idle for longer than
jcifs.smb.client.soTimeout jCIFS will transmit the appropriate loggoff
and disconnect messages and then close the underlying socket. This should
not generate an error on the server or the client.

Note that soTimeout is in *milliseconds*. The default is 15000 meaning
15 seconds. If you specify something like 3, thinking it's 3 seconds,
the transport will close before the request is sent or after it's sent
but before the response is received. In both cases this is not what you
want and will likely generate an error somewhere.

> @Michael: Would you kindly implement such a function , or do you accept a
> patch ?

If you can provide a compelling *reason* then yes. Otherwise, no.

In future versions this behavior will be changed slightly. In particular
refcounting will be used to block transports from closing so that
handles that are left open without activity remain valid. Currently if
you open a file and wait it will be closed when soTimeout expires and
then transparently reopened as necessary. This works but technically it
is bad and future functionality cannot be properly supported with the
current behavior (e.g. file locks).

Thanks,
Mike