I tried to copy a file following the example in the java and nutshell tutorials as listed below. I wrote a junittest that creates a file with one line of text. The file is there, it is found and opened and the text is there too until the call of file.read(buffer). That method returns -1, after the call the source file is empty and nothing is written to the targetFile.
Could that be connected to the 8 and 16bit problem mentioned in the java tutorial?
"Remember that FileReader and FileWriter read and write 16-bit characters. However, most native file systems are based on 8-bit bytes. These streams encode the characters as they operate according to the default character-encoding scheme. You can find out the default character-encoding by using System.getProperty("file.encoding"). To specify an encoding other than the default, you should construct an OutputStreamWriter on a FileOutputStream and specify the encoding."
Does anybody has a fileCopy function that copies any sort of file?
Are you sure that in your test, targetDrive and/or targetDir are different from sourceFile's drive and/or dir? Because the synptoms you describe are pretty much what you'd see if you were writing to the same file you're reading: opening it for output would truncate it to zero length.
Thank you for the hint! It was true: the source and target file was on the same drive AND dir, but the name was different. But I'm a bit puzzeled, because I don't recall having read I must not use the same drive nor directory. So I cannot save a file in the same directory under another name with that method? Would there be an alternative in java to do this? (I searched on the net for doc but could not find any? can you please give me a hint for documentation on this?)
I also wonder if someone with more IO expertise could tell me, if this copy method would be robust for any type of file (binary ansi8 or 16 etc)
Joined: Aug 21, 2001
Sorry, I saw the wrong thought, if the target drive and dir are the same, the method writes to the same file...
I added [code] tags to your first post above to try to fix the indentation for readability. Unfortunately it looks like your indentation was inconsistent. Mixing tabs and spaces is typically a bad idea for this reason - it looks funky when displayed in other formats.
I can't tell from your last comment if this means EFH's suggestion solved your problem, or not.
As for the question about whether it's robust for all file types - looks like it should be, yes. The comment from the tutorial was about Readers and Writers, not InputStreams and OutputStreams. If you were tryign to treat a binary file as text by using a Reader, that could cause problems. But InputStream and OutputStream just deal with bytes, regardless of what those bytes mean. You shouldn't have a problem here. Assuming you can write a new file at all - failure may occur for other reasons. Point is, the use of the InputStream and OutputStream looks good once they've been created.