NIO2's Path.moveTo(...) needs renameTo(...) aequivalent, or at least javadoc clarification.

[Alan Bateman]

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.

-Alan.