[jcifs] Exceptions "getting eaten" during SmbFile.copyTo

[Michael B Allen]

The 1.3.16 release now has a property called
jcifs.smb.client.ignoreCopyToException which defaults to true. Meaning
an exception that occurs trying to copy one file or directory will not
stop the overall copyTo operation. However, if the
jcifs.smb.client.ignoreCopyToException is set to false, any exception
that occurs in copyTo (such as a permissions error or locked file
error) it will be thrown out of copyTo and the copy will be aborted at
the point of failure.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

On Fri, May 15, 2009 at 9:43 PM, Michael B Allen <ioplex at gmail.com> wrote:
> On Tue, Mar 10, 2009 at 4:39 AM,  <cje at atp.dk> wrote:
>> Hi Michael
>> Thanks for your reply.
>>
>> I've commented the 3 lines out and it seems to do the job. Now any io error
>> during copy is reported and the copy is aborted.
>
> Actually looking at this closer it seems there is a reason for that
> try / catch. If you want to copy a big tree and one file fails because
> of permissions or something like that the copy will continue. You
> could argue that the copy should fail but this seems to be a matter of
> preference. So without a technical reason for changing this I'm not
> going to change the behavior.
>
> Perhaps in 2.0 when we have context specific properties there will be
> an property to indicate that the entire copy should be aborted for any
> exception.
>
> Mike
>
>> Re: [jcifs] Exceptions "getting eaten" during SmbFile.copyTo
>> On Tue, Mar 3, 2009 at 3:40 AM,  <cje at atp.dk> wrote:
>>> Hi.
>>> I'm working with v1.3.1. I experience exceptions "getting eaten" during
>>> copyTo. In SmbFile method
>>> void copyTo0( SmbFile dest, byte[][] b, int bsize, WriterThread w,
>>> SmbComReadAndX req, SmbComReadAndXResponse resp ) throws SmbException
>>> there's a try-catch block:
>>> } catch( Exception ex ) {
>>> if( log.level > 1 )
>>> ex.printStackTrace( log );
>>
>> Yeah, that is wrong.
>>
>> If you comment out those three lines (starting with } catch), are the
>> exceptions thrown as you would expect?
>>
>> I have to wonder why that catch is there at all.
>>
>> Another thing that could be done is to simply rethrow it by adding a
>> "throw ex;" after the printStackTrace.
>>
>> The "handle is invalid" error is of course a separate issue but for
>> the moment you might as well use that to fix the "exceptions getting
>> eaten" problem.
>>
>> Mike