[jcifs] question on fixes in 1.1.6

[Michael B Allen]

roy-jcifs at xemaps.com said:
> Hi Michael,
>
> BTW, I tried 1.1.6 last night on my local machine passing files back and
> forth
> from one folder to another via jcifs and saw different errors.  Just
> wanted to
> let you know.
>
> java.lang.InterruptedException
>         at java.lang.Object.wait(Native Method)
>         at java.lang.Object.wait(Unknown Source)
>         at jcifs.smb.SmbFile.copyTo0(SmbFile.java:1957)
>         at jcifs.smb.SmbFile.copyTo(SmbFile.java:2051)
>
> And then after that error:
>
> jcifs.smb.SmbException: Access is denied.
>         at jcifs.smb.SmbTransport.send(SmbTransport.java:704)
>         at jcifs.smb.SmbSession.send(SmbSession.java:249)
>         at jcifs.smb.SmbTree.send(SmbTree.java:103)
>         at jcifs.smb.SmbFile.send(SmbFile.java:725)
>         at jcifs.smb.SmbFile.open0(SmbFile.java:863)
>         at jcifs.smb.SmbFile.open(SmbFile.java:881)
>         at jcifs.smb.SmbFile.copyTo0(SmbFile.java:1934)
>         at jcifs.smb.SmbFile.copyTo(SmbFile.java:2051)
>
> The folders have full access and at that point in my test run, a couple
> hundred of files were already copied.  I also still have some questions on
> the
> errors we discussed before.

What does your progam look like. Can you send it to me?

I think there might be more going on here outside of jCIFS. Meaning you
might have a flakey network. Check to see if your network card is
full-duplex or half or whatever it should be.

Can you get a packet capture?

http://jcifs.samba.org/capture.html

> On Tue, 28 Dec 2004 17:22:43 -0500 (EST), Michael B Allen wrote
>> Actually from looking at these a little closer I think these might be
>> related to some kind of network failure. Specifically if there is a
>> socket
>> error and the transport thread tries to close stuff while operations
>> are in progress I think these sorts of errors can result.
>
> Is there any way to avoid these errors?
>
>> roy-jcifs at xemaps.com said:
>> > jcifs.smb.SmbException: The handle is invalid.
>> > 	at jcifs.smb.SmbTransport.send(SmbTransport.java:704)
>> > 	at jcifs.smb.SmbSession.send(SmbSession.java:234)
>> > 	at jcifs.smb.SmbTree.send(SmbTree.java:103)
>> > 	at jcifs.smb.SmbFile.send(SmbFile.java:724)
>> > 	at jcifs.smb.SmbFile.copyTo0(SmbFile.java:1935)
>> > 	at jcifs.smb.SmbFile.copyTo(SmbFile.java:2034)
>>
>> This one is coming from the server. If an error occurs, things are
>> closed, and the timing is such, this is the sort of error that would
>> pop up.
>
> OK, but I'm accessing these file one at a time.  Why would these errors
> still
> occur?  And I'm not too familiar with the code so I'm not understanding
> what
> you mean by the "timing".

The copyTo function uses a WriterThread to write while the main thread is
busy reading. If the socket get's into a bad state (e.g. because of a
network error) one thread will get a socket error but the other may get a
different error. It's really difficult to tell what sort of errors can
occur if the transport is in an error state to begin with. This assumes
that there really is a netork problem of course. I don't that it is but
you're getting so may different kinds of errors it just seems odd.
Certainly someone else would have reported the problem by now. 1.1.3 was
released a month ago.

>> > java.lang.NullPointerException
>> >         at
>> > jcifs.smb.AndXServerMessageBlock.readWireFormat(AndXServerMessageBloc
>> > k.java:99)
>> >         at jcifs.smb.SmbTransport.run(SmbTransport.java:483)
>> >         at java.lang.Thread.run(Thread.java:534)
>>
>> In this case the 'in' socket is null which is passed to the readXxx
>> methods by the transport. Again if a socket error occurs while
>> operations
>> are in-flight this is the sort of thing that could happen.
>
> This one in our case is a biggy since we have threads waiting on the
> copyTo to
> return.  If we check our thread and kill it if too much time has passed,
> will
> the above SmbTransport thread still be running on its own or is it dead?

Wha? First, why would you kill the thread? The response timeout limit is
10 seconds. If copyTo talks longer than that then that means it's actually
transmitted and received a response in the last 10 seconds. I thought you
said you're only copying one file at a time? How many threads are you
using? Also, if you interrupt a thread communicating on a socket the
socket can become indefinately useless. It sounds like you're doing some
weird things. What are you ultimately tring to do?

>
>> I'm not certain I should try to hunt down and kill these. The transport
>> layer is a little fragile and I don't want to futz with it just to
>> gracefully deal with socket failure.
>>
>> Incidentally it so happens that at this very moment I'm working on a
>> new Transport abstract base class for 2.0 that synchronizes
>> everything with a single lock. Currently jCIFS uses a couple of
>> locks which is just asking for big trouble.
>>
>> You would be surprised how difficult it is to write serious network
>> software in Java. Simple one caller / one thread / one socket stuff
>> is trivial but when you're multiplexing I/O like we are the Java
>> thread model and network facilities are pretty bad.
>
> I thought about trying to fix some of the problems myself, but took one
> look
> at the code and decided to leave it to the experts ;)  Is there any reason
> why
> java does not support cifs internally?

Actually if you're using Windows you can use UNC paths like:

  File f = new File( "\\\\server\\path\\file.txt" );

And of course you can also map a drive and do:

  File f = new File( "H:\\path\\file.txt" );

Mike