Submitted On 21-NOV-1997
elharo
If the renameTo method really moves a file,
then it only makes sense that there be
a copy method too.
Submitted On 02-JUL-1999
invalidname
Why doesn't java.io.File have a copy? For that matter, why does it return
booleans instead of throwing exceptions? Why can File.renameTo() fail when
moving across network filesystems, when there is no way for a developer to know
that the source and target are on different filesystems?
java.io.File needs a major rewrite. With a copy method.
Submitted On 19-JUL-1999
mroshea
Agreed. renameTo is the method that is biting me
at the moment, but the evaluation above is a bit
of a cop out! If File.copy doesn't exist, can you
at least suggest a reasonably efficient substitute?
Submitted On 03-AUG-2001
anand000
need favor
Submitted On 07-DEC-2001
perrella
I cannot see how copying a file would vary by platform. I
can see how copying the file using java would vary by
platform. Every OS EXCEPT UNIX has file copy built into a
standard function library. So using the excuse that this is
ok since UNIX doesn't provide it is lame. Also, I'm certain
that a natively written file copy will be better for the
following reasons:
1. permissions, ACLs, etc. will be copied
2. speed will be much better than with Java.
3. The JDK writers can take the time to write a fast copy
routine instead of having everybody and their mother's
writing their own lame versions.
Submitted On 05-MAR-2004
merkisoft
Sun: those should be reasons?
it's missing and everyone wants it. so? implement it!
Submitted On 03-FEB-2009
mike40033
Sun says : "You can easily do this yourself".
I say : Yes, but 1 line of code is better than 6 or 7.
Sun says "Its behaviour would vary widely across platforms"
I say : Explain how so, instead of dismissing a real problem with a patronising throwaway line. Copying is a standard operation. If in doubt, just specify "copyTo is equivalent to renameTo, but does not remove the original file".
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|