File Transfer using Transferto() function:File not deleted from source
hi i was stuck on the following. I was attempting to implement file transfer using the transferto() function. The file is copied to teh destination but not deleted from the source folder.
Kindly revert back if some one knows the way out.
boolean success=true;
FileInputStream fIn;
FileOutputStream fOut;
FileChannel fIChan, fOChan;
long fSize;
File dest = new File(destination);
if(dest.exists())
dest.delete();
try{
fIn = new FileInputStream(source);
fOut = new FileOutputStream(destination);
fIChan = fIn.getChannel();
fOChan = fOut.getChannel();
fSize = fIChan.size();
fIChan.transferTo(0,fSize,fOChan);
fIChan.close();
fIn.close();
fOChan.close();
fOut.close();
success = dest.exists();
if(success=true)
{
Thread.sleep(5000);
File src = new File(source);
success = src.delete();
}
}
catch (IOException exc){
System.out.println("IOException" + exc);
System.exit(1);
}
catch (ArrayIndexOutOfBoundsException exc){
System.out.println("Usage: Copy from to");
System.exit(1);
}
catch (InterruptedException e1){
System.out.println("InterruptedException " + e1);
System.exit(1);
}
I don't see anything in the API that says that transferTo() would delete a file...
By the way, just shutting down the JVM in case of an exception is a pretty inconsiderate thing to do as you don't even "finally" close the channels. You might leave some file locks open...
And catching RuntimeExceptions like this is just a no-no and an attempt to try to cover up for programming mistakes.
> if(dest.exists())
> dest.delete();
Redundant. You're about to clobber the destination file with the FileOutputStream constructor anyway.
> fIChan.transferTo(0,fSize,fOChan);
Don't ignore the return value of this method. You need to call this thing in a loop until it has transferred all the bytes.
> fIChan.close();
> fIn.close();
One of those closes is redundant.
> fOChan.close();
> fOut.close();
Ditto.
> if(success=true)
Yuck. You mean 'if (success)'. This is just wasting the time of the compiler, the JVM, and the reader. Especially the reader.
> Thread.sleep(5000);
Why?
> File src = new File(source);
> success = src.delete();
Don't ignore this result either. What was it?
ejpa at 2007-7-8 22:55:28 >
> > if(success=true)
>
> Yuck. You mean 'if (success)'. This is just wasting
> the time of the compiler, the JVM, and the reader.
> Especially the reader.
Actually this expression as the OP wrote it will always resolve to "true" since he's missing a second '=', and thus is highly likely to be a bug.
> success = dest.exists();
>
> if(success=true)
This assignment and test are also redundant, not to mention the bad practice which has led to the programming error pointed out above by CNEPUP. If you couldn't create the file you would have thrown an IOException by now.
ejpa at 2007-7-8 22:55:28 >
hi all..
if (success==true)
{
Thread.sleep(5000);
File src = new File(source);
success = src.delete();
}
attempts to delete the file from the source after it is copied to the destination...
Thread.sleep(5000) was intended to give the JVM sufficient time so that we might be able to supersede the file locks if any...
success variable is read from at the end..
return success;
the whole intent was that while attempting file transfer from source to destination..files are COPIED and NOT TRANSFERRED..the said file(s) should not be present in the SOURCE folder after the transfer....
boolean success=true;
FileInputStream fIn;
FileOutputStream fOut;
FileChannel fIChan, fOChan;
long fSize;
File dest = new File(destination);
if(dest.exists())
dest.delete();
try{
fIn = new FileInputStream(source);
fOut = new FileOutputStream(destination);
fIChan = fIn.getChannel();
fOChan = fOut.getChannel();
fSize = fIChan.size();
fIChan.transferTo(0,fSize,fOChan);
fIChan.close();
fIn.close();
fOChan.close();
fOut.close();
success = dest.exists();
if(success==true)
{
//Thread.sleep(5000);
File src = new File(source);
success = src.delete();
}
}
catch (IOException exc){
System.out.println("IOException" + exc);
//System.exit(1);
}
catch (ArrayIndexOutOfBoundsException exc){
System.out.println("Usage: Copy from to");
//System.exit(1);
}
catch (InterruptedException e1){
System.out.println("InterruptedException " + e1);
//System.exit(1);
}
return success;
> attempts to delete the file from the source after it
> is copied to the destination...
Err, yes, we got that. Amazingly enough ...
> Thread.sleep(5000) was intended to give the JVM
> sufficient time so that we might be able to supersede
> the file locks if any...
What file locks? You didn't lock the files, and if someone else did your method would fail anyway when the file is opened. And how is waiting 5 seconds going to help? Why not 10? Why not 48 hours? ...
> success variable is read from at the end..
> return success;
Obviously, but it's not very informative, is it? If your code worked as designed, which it doesn't, 'false' could mean either 'destination doesn't exist' or 'source wasn't deleted'. How is the caller going to cope with these two fairly different situations if you describe them both with a single state?
> the whole intent was that while attempting file
> transfer from source to destination..files are COPIED
> and NOT TRANSFERRED..the said file(s) should not be
> present in the SOURCE folder after the transfer....
Err, yes, we got that too, except that you mean 'moved not copied'. No need to SHOUT thanks.
The non-formatted repetition of the same non-formatted source code shows that you've applied just one of the several improvements suggested above. What happened when you tried the others?
ejpa at 2007-7-8 22:55:28 >
