Re: FIle being kept upon until +/- 20 seconds after I close its InputStream

Hi Michael,

Thank you for your response.

Unfortunately the solution you suggest does not work. It also doesn't
matter whether I replace the line where the input stream is opened with
  SmbFileInputStream in = new SmbFileInputStream(file);
or with:

  SmbFileInputStream in = new SmbFileInputStream(file.toString());

In all cases, the same thing happens: a thread called Transport1 keeps
open the connection and the file and only dies after 20 seconds because of
a timeout.

Looking at the JCIFS code I found that SmbFile.getInputStream() actually
returns a new SmbFileInputStream so this doesn't surprise me. Any other
other hints or tips?

The only thing I could think of was to subclass SmbFile to expose its
innards and manually call the transport with
tree.session.transport.disconnect(true) when I'm done reading a file. But
that makes me feel dirty. ;-)

Regards, Vincent.

P.S. Thanks for the tip about using NtlmPasswordAuthentication. That also
saves me having to encode special characters in the SMB URL. New release
of Overthere <https://github.com/xebialabs/overthere> coming up! :-)

On 25-01-12 21:18, "Michael B Allen" <[email protected]> wrote:

>Hi Vincent,
>
>SmbFile shares it's InputStream. Use SmbFileInputStream instead. Then
>close() will really close the file.
>
>Mike
>
>-- 
>Michael B Allen
>Java Active Directory Integration
>http://www.ioplex.com/
>
>PS: Note that you should not use credentials in the URL for anything
>other than trivial testing. The NtlmPasswordAuthentication object
>should be used to manage credentials.
>
>On Wed, Jan 25, 2012 at 11:41 AM, Vincent Partington
><[email protected]> wrote:
>> Hi there,
>>
>> When I run the program below, the file I am reading is being kept upon
>>+/-
>> 20 seconds after the close() method has been invoked. This means that it
>> cannot be accessed by other files, e.g. executables I run on that
>>Windows
>> box.
>>
>> public void shouldReadFile() throws IOException {
>>
>> SmbFile file = new
>> 
>>SmbFile("smb://Administrator:secret@win-s2008r2/C$/windows/temp/overthere
>>-20120125T170658757.tmp/large.dat");
>>
>> byte[] largeFileContentsRead = new byte[1 * 1024 * 1024];
>>
>> InputStream in = file.getInputStream();
>>
>> try {
>>
>> ByteStreams.readFully(in, largeFileContentsRead);
>>
>> } finally {
>>
>> in.close();
>>
>> }
>>
>> System.out.println("Done!");
>>
>> }
>>
>>
>> For about twenty seconds after close() is called, the following can be
>>seen
>> on the target machine:
>>
>> PS C:\Users\Administrator\desktop> .\handle.exe large
>>
>> Handle v3.46
>> Copyright (C) 1997-2011 Mark Russinovich
>> Sysinternals - www.sysinternals.com
>>
>> System             pid: 4      type: File          31A4:
>> C:\Windows\Temp\overthere-20120125T170658757.tmp\large.dat
>>
>>
>> Also netstat is reporting that there is still a connection:
>>
>> C:\Windows\Temp>netstat
>>
>> Active Connections
>>
>>   Proto  Local Address          Foreign Address        State
>>   TCP    172.16.172.179:445     TIMMY:51613            ESTABLISHED
>>
>>
>>
>> I have been able to track this down to the transport thread that is
>>still
>> working on that connection until it receives a socket timeout and closes
>> itself "hard". But I have no idea what is causing that timeout. Does
>>anybody
>> have any what is going on? This happens with Jcifs 1.3.3 and 1.3.17.
>>
>> BTW, when I write to a file this does not happen!
>>
>> Thanks in advance! Regards, Vincent.
>>