How about the core API, with FileInputStream and FileOutputStream? Read from the FileInputStream and copy to the FileOutputStream. Then, when you've written 1GB, close the FileOutputStream and open a new one.
Pasting them together is similar. Copy all contents from the FileInputStream to the FileOutputStream. Then, when the FileInputStream has been read, close it and open the next one, writing to the same FileOutputStream.
The program is like below but it hangs when ever i want to split any file of 2gb or beyond.Even if the folder am not able to do a ls -ltr after running the splitme pro.
I know something is foolishly wrong can somebody please take a look at it.
2GB is 2 * 1024 * 1024* 1024 bytes = 2,147,483,648 bytes. Integer.MAX_VALUE is 2,147,483,647, one smaller. So when you read the long value and cast it to int, it will wrap around and become -2,147,483,648 instead. As such, the check "leng<splitlen" will never be true, the inner while loop will never execute and you never read any data anymore. As a result, data will keep the value of the first byte forever.
Instead of limiting your splitlen to int, make it long. Also, disallow negative values; if someone types in -1 the same will occur.>
Sorry for too many similes. I changed to long its working but the speed of splitting is very slow almost takes 3 and 1/2hrs to split a 3GB file in 2GB slices.
Is there anything I can do to make it faster. Any suggestions for Better performance??
Switch from RandomAccessFile to InputStream and OutputStream, then use BufferedInputStream and BufferedOutputStream. So your code changes as this (leaving out unchanged code):
Since InputStream and OutputStream also have the read() / write() and close() methods that should cause your code to compile without any problems.
I don't know if it is the InputStream that is making the difference; I think it's the BufferedInputStream. The RandomAccessFile really reads one byte at a time, whereas the BufferedInputStream reads chunks of multiple bytes, even if you only call the read() method that returns one byte. Reading multiple bytes (usually entire "pages" of several kilobytes) is usually much more efficient.