NIO2's Path.moveTo(...) needs renameTo(...) aequivalent, or at least javadoc clarification.
Alan.Bateman at Sun.COM
Tue Dec 22 06:47:52 PST 2009
Joel Uckelman wrote:
> I'm not clear on the distinction between moving and renaming here. I
> understand that in certian cases (e.g., when a file is moved from one
> filesystem to another) moving a file results in copying all of its data,
> while in other cases it does not (e.g., same-filesystem moves). Is this
> the distinction which is being made between moving (which might involve
> copying) and renaming (which does not involve copying)?
> If there could conceivably be cases where renaming could still involve
> a copy, then I think it's best to name the flag NOCOPY_ALLOWED to reflect
> what it does, rather than RENAME_ONLY, which only reflects its (presently)
> intended use.
That is fair comment as we can't make assumptions for all providers.
At this time, the moveTo method doesn't make any distinction, in the
javadoc, between renaming and moving. That is, source.moveTo(target) or
source.moveTo(target, REPLACE_EXISTING) should "just work" and it
doesn't matter if you are simply giving a file a new name in the same
directory or moving the file to another directory (that is on the same
or a different file system/volume). In the case of the default provider,
then it will always attempt to rename the file and only fall back to a
copy+delete if the rename fails because the target is a different file
system/volume. If the target is associated with a different provider
then moveTo will always copy+delete (as rename doesn't make sense). The
suggestion that has come up, is to introduce a new rename method that
will be "fast" or rather won't fall-back to a copy+delete. The
ATOMIC_MOVE option actually does this already (at the implementation
level anyway) but that option is for a different use-case and can't
guarantee behavior when the target already exists.
More information about the nio-dev