• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

why does this file copy not work?

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I tried to copy a file following the example in the java and nutshell tutorials as listed below. I wrote a junit test 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?

Thanks for help!

[ March 07, 2006: Message edited by: Jim Yingst ]
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
mark baum
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ernest,

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)

Thanks
 
mark baum
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, I saw the wrong thought, if the target drive and dir are the same, the method writes to the same file...
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"baum", your recent name change is incompatible with our display name policy. Please give it a read and change your display name to include a first and last name. Thanks.

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic