[jcifs] a bug
Allen, Michael B (RSCH)
Michael_B_Allen at ml.com
Tue Jan 15 16:33:13 EST 2002
> -----Original Message-----
> From: Dmitry [SMTP:surfer at ok.ru]
> Sent: Tuesday, January 15, 2002 12:08 AM
> To: Allen, Michael B (RSCH)
> Subject: Re: [jcifs] a bug
>
> On Mon, 14 Jan 2002 23:40:20 -0500
> "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com>
> wrote:
> >
> >> -----Original Message-----
> >> From: Dmitry Krasnikov [SMTP:duke at land81.nsu.ru]
> >>
> >> When i have downloaded jCIFS first time it was 0.6b5
> >>version. I've tried
> >> to use it to list dirs, containing upper-127 characters
> >>in name and came
> >> to a strange bug - we could get dir listing using
> >>listFiles() and we could
> >> get file names but exception was thrown when we tried to
> >>get size of
> >> files...
> >>
> > What kind of Exceptions? What bug do you refer to?
>
> directory not found...
> i've used such construction
>
> SmbFile f=new SmbFile(host+"/"+urlEncode(dir));
> SmbFile[] lists=f.listFiles();
>
> when we were using lists[i].getName() evrth was fine but
> when we were using lists[i].length() "directory not
> found... " (or resiurce not found) exception were
> thrown... that bug does not appear in 0.6b8.
>
Ok, I think that was the attribute caching problem.
> >
> > So does this trigger the problem?
> >
> > import java.net.*;
> > import jcifs.smb.*;
> >
> > public class LF {
> >
> > public static void main( String[] argv ) throws
> >Exception {
> > SmbFile[] list;
> >
> > SmbFile dir = new SmbFile(
> >"smb://miallen1/Download/%ED%D5%CC%D8%D4%C9%CB%C9" );
> >
> > list = dir.listFiles();
> > for (int i = 0; i < list.length; i++) {
> > System.out.println( list[i] + " " +
> >list[i].length() );
> > }
> > }
> > }
> >
> > I get
> >
> > [miallen at miallen2 examples]$ java
> >-Djcifs.properties=../../miallen.prp LF
> > smb://miallen1/Download/%ED%D5%CC%D8%D4%C9%CB%C9/d0.c
> >1306
> > smb://miallen1/Download/%ED%D5%CC%D8%D4%C9%CB%C9/d1.c
> >799
> > smb://miallen1/Download/%ED%D5%CC%D8%D4%C9%CB%C9/goob 0
> > smb://miallen1/Download/%ED%D5%CC%D8%D4%C9%CB%C9/lib 0
> > smb://miallen1/Download/%ED%D5%CC%D8%D4%C9%CB%C9/Makefile
> >207
> > smb://miallen1/Download/%ED%D5%CC%D8%D4%C9%CB%C9/README.txt
> >1426
> > smb://miallen1/Download/%ED%D5%CC%D8%D4%C9%CB%C9/s3.xml
> >921
> >
> > Which looks like it's working for me.
>
> yes, when i'm creating the same class for test it into one
> directory it works fine... it lists contents end exit
> correctly
>
> when i'm using your classes in smb:// scan process it
> works with almost all dirs and finally falls on one...
>
Do you mean the SmbCrawler examples?
>
> once again, when i'm reproducing the situation mannualy by
> giving order to list contents of dir everything worked
> fine. (by the way... directory does not named
> %ED%D5%CC%D8%D4%C9%CB%C9 - it named in unescaped sequence)
>
So then at what point did it get encoded?
> >
> > I need more information. Can you reproduce the problem
> >consistently?
> >
> > Are there many files in the directory?
>
> 2 files, english letters only... THE PROBLEM IS: SmbFile
> works correctly... it gets dir... gets listFiles() outputs
> them... my program parses them... and then little timeout
> in program executing appears and i'm getting socket closed
> exception... it's strange that exception is thrown in some
> thread that i'd never used... I guess you package starts
> your own threads and exception appears right there...
> after that any call to samba functions from you package
> does not work properly.
>
I think I know what this Socket closed exception is. Here's an example:
[miallen at miallen2 examples]$ java -Djcifs.properties=../../miallen.prp ListFiles smb://yoyo/IPC$
Jan 15 00:09:22.765 - exception reading from socket input
java.net.SocketException: Socket closed
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java, Compiled Code)
at jcifs.netbios.SessionServicePacket.readPacketType(SessionServicePacket.java, Compiled Code)
at jcifs.netbios.SocketInputStream.read(SocketInputStream.java, Compiled Code)
at jcifs.netbios.SocketInputStream.read(SocketInputStream.java, Compiled Code)
at java.io.FilterInputStream.read(FilterInputStream.java, Compiled Code)
at java.io.PushbackInputStream.read(PushbackInputStream.java, Compiled Code)
at jcifs.smb.SmbTransport.run(SmbTransport.java, Compiled Code)
at java.lang.Thread.run(Thread.java, Compiled Code)
Exception in thread "main" jcifs.smb.SmbException: Timeout waiting for response from server. yoyo<20>/172.34.36.38
at jcifs.smb.SmbTransport.sendTransaction(SmbTransport.java, Compiled Code)
at jcifs.smb.SmbSession.sendTransaction(SmbSession.java, Compiled Code)
at jcifs.smb.SmbTree.sendTransaction(SmbTree.java, Compiled Code)
at jcifs.smb.SmbFile.sendTransaction(SmbFile.java, Compiled Code)
at jcifs.smb.SmbFile.listFiles(SmbFile.java, Compiled Code)
at jcifs.smb.SmbFile.listFiles(SmbFile.java, Compiled Code)
at jcifs.smb.SmbFile.listFiles(SmbFile.java, Compiled Code)
at ListFiles.main(ListFiles.java, Compiled Code)
In the above example I try to do listFiles on the IPC$ share (interprocess communication). This is not
something you want to do because IPC$ is not a file service. So what happends is the server never
responds to the request and the client times-out. This will trigger tryClose to be called which will close the
socket. The input end of the socket will then throw "Socket closed" because jCIFS closed it. This is all
normal and the socket should be reestablished gracefully provided you skip the resource that provoked
the error..
Are you using one of the SmbCrawler examples? If so, these programs are just examples. They are not
smart enough to not do a listFiles operation on IPC$ and such. They are very simple *examples*.
Dmitry,
I'm a little confused now. I don't think any of this has to do with URLEcoder/Decoder. I think you're just
seeing some timeouts for doing invalid things. If you are not using the Crawler examples then you might
have a legitimate bug but we have to narrow the issue down a little.
Mike
> >
> > Does the problem go away if you change these properties
> >to:
> >
> > soTimeout=600000
> > attrExpirationPeriod=1
> > attrExpirationPeriod=600000
>
> wait a little i'll try
>
> >
> > If so which setting?
> >
> > Can you capture a trace with -Dlog=ALL VM flag while
> >this happends? Send it to me directly.
> >
> > PS: You know you don't have to URL encode those Russian
>
> i shoud due to unavailability to switch to not urlencoded
> dir...
> for instance, i'm getting exception by listing contents of
> dir that named as we talking about but i do not getting
> exception by listing it content in urlencoded request.
> ---
> Professional hosting for everyone - http://www.host.ru
More information about the jcifs
mailing list