Skip to main content

file copy

15 replies [Last post]
ulfzibis
Offline
Joined: 2005-02-18
Points: 0

I propose for the java.io.File class :

boolean copyTo(File dest)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ulfzibis
Offline
Joined: 2005-02-18
Points: 0

> To my knowledge all implementations use an OS-specific rename operation, thus they never copy physically.

You think, OS-Specific rename operations will never copy to annother device ?
On windows, I think, you are right. But when I remember right to my little Linux experience, I think you could rename from on device to another, because based on the pathname you can't see if some files are physically on the same device.

> Anyway, I think when restricting [b]copyTo()[/b] to
> files only, this operation could be a valuable
> extension to the [b]File[/b] class. Convinced, so to
> speak :)
I am convinced on this

michi295
Offline
Joined: 2005-02-19
Points: 0

> I was in error: [i]renameTo()[/i] only works for
> [u]single files[/u], so [i]copyTo()[/i] also should
> only work for [u]single files[/u].

According to the API doc [b]renameTo()[/b] is [i]not[/i] restricted to files so it also applies to [i]directories[/i] which would complicate it for the [b]copyTo()[/b] case.

> Javadoc 5.0 says:
> [i]The rename operation might not be able to move a
> file from one filesystem to another, it might not be
> atomic, [/i]
> 1. --> it might be able to move a file from one
> filesystem to another means that it [b]physicly
> copies[/b] a file, and then deletes it's origin. So
> why not provide an explicit copy method ?

To my knowledge all implementations use an OS-specific rename operation, thus they never copy physically.

> 2. --> it might [u]not[/u] be atomic '\=o-o=/' O :
> - ) (=gloriole)

Argh, you're right, I stand ashamed :( I only read the 1.4 API docs which are not as precise at the 5.0 docs... I have to admit this horrifies me quite a bit - what if a non-atomic rename operation succeeds partially???

> As described above, [i]removeTo[/i] can be a copy.
> Then the [i]copyTo[/i] case is [u]not[/u] much
> different

As described above, [b]renameTo()[/b] never actually is a copy, thus the [b]copyTo()[/b] case would be different :/

Anyway, I think when restricting [b]copyTo()[/b] to files only, this operation could be a valuable extension to the [b]File[/b] class. Convinced, so to speak :)

ulfzibis
Offline
Joined: 2005-02-18
Points: 0

> According to the API doc [b]renameTo()[/b] is
> [i]not[/i] restricted to files so it also applies to
> [i]directories[/i] which would complicate it for the
> [b]copyTo()[/b] case.

It's not restricted, but all methods in class [i]File[/i], which work on files [u]and[/u] directories, are mentioned as those. So we must ask the designers of Java for what there intention was for [i]renameTo[/i], and control, if the implementation follows it.

michi295
Offline
Joined: 2005-02-19
Points: 0

Not exact enough. What would be returned when the copy operation was only partially successful, true or false?

[b]renameTo[/b] returns true iff the operation was successful, false otherwise. It cannot fail [i]partially[/i] because it only does an atomic rename attempt (so tells the documentation), it surely does [i]not[/i] a recursive rename. The [b]copyTo[/b] case would be much different, so I'm afraid there won't be a generally useful definition of its semantics. But - hey, c'mon, convince me of the contrary :)

ulfzibis
Offline
Joined: 2005-02-18
Points: 0

> Not exact enough. What would be returned when the
> copy operation was only partially successful, true or
> false?

I was in error: [i]renameTo()[/i] only works for [u]single files[/u], so [i]copyTo()[/i] also should only work for [u]single files[/u].

> [b]renameTo[/b] returns true iff the operation was
> successful, false otherwise. It cannot fail
> [i]partially[/i] because it only does an atomic
> rename attempt (so tells the documentation), it
> surely does [i]not[/i] a recursive rename.

Javadoc 5.0 says:
[i]The rename operation might not be able to move a file from one filesystem to another, it might not be atomic, [/i]
1. --> it might be able to move a file from one filesystem to another means that it [b]physicly copies[/b] a file, and then deletes it's origin. So why not provide an explicit copy method ?
2. --> it might [u]not[/u] be atomic '\=o-o=/' O : - ) (=gloriole)

> The [b]copyTo[/b] case would be much different, so I'm
> afraid there won't be a generally useful definition
> of its semantics. But - hey, c'mon, convince me of
> the contrary :)

As described above, [i]removeTo[/i] can be a copy. Then the [i]copyTo[/i] case is [u]not[/u] much different

vpatryshev
Offline
Joined: 2004-06-30
Points: 0

Not on Windows. On Windows the implementation uses WIN32 wrename, and it does not copy anything, but fails if files are on different drives. Semantics on other platforms may vary. I'd love to see working something like rename("http://yahoo.com", "file://tmp/cache/yahoo.com");

mthornton
Offline
Joined: 2003-06-10
Points: 0

The boolean success/failure is a feature which should NOT be copied. Not knowing why the operation has failed has caused endless confusion amongst developers.

ulfzibis
Offline
Joined: 2005-02-18
Points: 0

I agree with you, but now we must live with it.
Explicit exceptions should be better.

vpatryshev
Offline
Joined: 2004-06-30
Points: 0

[code]
FileInputStream is = new FileInputStream(from);
FileOutputStream os = makeFile(to);
os.getChannel().transferFrom(is.getChannel(), 0, from.length());
is.close();
os.close();
[/code]

ulfzibis
Offline
Joined: 2005-02-18
Points: 0

1.) [i]makeFile()[/i] is your library, and not Java. :-(
2.) I suppose, that the underlaying OS has a copy function, and I also suppose, this would be faster than shifting thousands of bytes by the JVM. So I propose to use it by native access.

vpatryshev
Offline
Joined: 2004-06-30
Points: 0

regarding makeFile(), it's not a big deal - do mkdirs(), then create FileOutputStream.

michi295
Offline
Joined: 2005-02-19
Points: 0

What would be this method's exact semantics, e.g. when copying a directory to another directory and some of the source files can not be copied to the destination?

ulfzibis
Offline
Joined: 2005-02-18
Points: 0

The same as:

[b]boolean renameTo(File dest)[/b]

except that the original file/directory not should be deleted.

vpatryshev
Offline
Joined: 2004-06-30
Points: 0

Oh! You are looking for a tree copy! Check out my http://myjavatools.com :)

ulfzibis
Offline
Joined: 2005-02-18
Points: 0

Very nice library. Thankx for the hint.

How you deal, if copying partially successes ?