This one is simple.  At least two platforms, the BeOS and the MacOS, have file
metadata.  This metadata cannot be copied in a platform independent way,
which makes it very difficult to make a backup copy of a file before writing
the new one.  (I know I can rename the file, but that is not always appropriate,
if I intend to append, rather than rewrite fresh)

In order to do a file copy on the MacOS, I need different code than for the
Windows and Solaris platforms.  It is my expectation that file metadata is
going to get more common, and that a simple, universal method for copying
data would be useful.  If such a method were provided, then it would be up
to the platform vendors to implement it in a way that properly dealt with
resource forks, attributes, and metadata, but the individual developer
would not have to.

Finally, this can cover the issue of permissions on Unix platforms.  If a
program makes a copy of the file, then the permissions and owner
could be copied as well.

Since it is a simple method, the signature would be something like

copy(File destination, boolean overwrite, boolean copyMetadata) throws IOException

overwrite is not all that needed, since it is not that hard to check for
existence first, and, in my mind, copyMetadata should be the default
behavior all of the time, but some may complain that they do not
always want all permissions, etc. to be copied.

Scott
(Review ID: 29718)
======================================================================




java version "1.1.6"

While trying to copyfiles, the developer has to use the read/write methods on
files. This results in the destination having the latest timestamp as opposed to
that of the original file.
We need a mechanism that essentially results in a filecopy.
(Review ID: 100727)
======================================================================
Posted Date : 2005-08-25 16:27:04.0

The only workarounds are platform specific, which is the complaint.  JConfig apparently has some cross platform solutions, but is not a part of the standard API, and may have licesnsing issues.
======================================================================




JNI
(Review ID: 99490)
======================================================================




The only (unacceptable) workaround is to have native implementation for copying
files.
(Review ID: 100727)
======================================================================

This feature has been addressed by the new file system API defined by JSR-203. The Path.copyTo method may be invoked with the COPY_ATTRIBUTES option that will attempt to copy all the file metadata including named streams.
Posted Date : 2009-02-16 13:27:45.0

>[JConfig] is not a part of the standard API
Not like I haven't tried:
http://www.tolstoy.com/samizdat/lysenkoism.html

It's also worth noting that on platforms without file metadata (Windoze, Unix),
the only option to copy files is to open Input- and OutputStreams and copy
blocks... probably faster if the JVM can just call upon the OS to do the copy.
IMHO, between the cross-platform weaknesses of java.io.File and its insistence
on returning booleans instead of throwing exceptions, the whole class is aching
for a total rewrite.

>The only (unacceptable) workaround is to have native 
>implementation for copying
>files.

What's unacceptable about this? Sun adds it to java.io.File
and each JVM vendor implements it with native code. Result 
is 100% as its part of the core API.

Whether the vendor's implementation is complex or simple is 
irrelevant, the problem would be solved.

java.io.File makes some seriously broken assumptions about 
files (i.e. all files look like Unix files) of which this 
is only one :-(

LordPixel:

If Sun and the jvm vendors need native code, I am not 
concerned.  The problem is that we, as developers, need to 
write native code to copy metadata, and this native code is 
not likely to be written for the platforms you do not use.  
Something as simple as Unix permissions, MacOS creators, 
and Windows create/modify dates are likely to be wrong.

If they put a method in with a signature like I asked for 
above, then at least a jvm vendor would have a chance, but 
without it, how is a vm to know that this particular "open 
and write" block of code was really a copy?

Having a method to copy metadata would also work, but it is 
less elegant, I suspect.

Windows Font files also seem to have metadata. When I copy them in Java, the copies don't get recognized as valid font files.