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

Hi Michael,

While the fact that the file is being kept open for another 20 seconds
after it has been closed for reading seems odd, it turned out it was not
the cause of our problem. Some other part of our code was keeping the
stream open. Sigh.

Thanks for your help! Regards, Vincent.

On 26-01-12 09:19, "Vincent Partington" <[email protected]> wrote:

>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/overther
>>>e
>>>-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.
>>>
>