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

[John Hendrikx]

Alan Bateman wrote:
> Salter, Thomas A wrote:
>> It seems like Path could use a getSibling(String name) method which 
>> effectively replaces the last node of the path with the name 
>> parameter.  Then your code could be:
>>   oldFile.moveTo( oldFile.getSibling( newNameString ) );
>>
>> I'd guess it's a fairly common occurrence to want to get the name of 
>> a file in the same directory as a known file, like a .h that goes 
>> with a .c file.
>>   
> There is merit in this. Most of the time it's just 
> foo.getParent().resolve(bar) but we have the corner-case where the 
> path is a simple file name. The corner case means we have to something 
> like this:
>
>    Path resolveSibling(Path file, String name) {
>        Path dir = file.getParent();
>        return (dir != null) ? dir.resolve(name) : 
> file.getFileSystem().getPath(name);
>    }
I indeed do it as:

path.moveTo(path.getParent().resolve(newName));

But I think in my case, path always has a valid parent.

>> Wouldn't it be good, to create a Path.renameTo(String newName) method?
>>   
> It's also possible to rename to other locations in the file system. 
> That's what File.renameTo(File) does. So f.renameTo(new File("bar")) 
> will attempt to rename f into the current directory (not necessarily 
> f's directory).  Path.moveTo(Path,CopyOption...) is just more general 
> and gives you control on if an existing file is replaced or not.
>
> There was a question on this mailing list back in September asking for 
> a way to rename, guaranteeing that the file isn't copied. If we have 
> that then rename becomes:
>  source.moveTo(target, NOCOPY_ALLOWED)
That might have been me.  I'm still in favor of having a distinct rename 
method, even if it just redirects to moveTo internally, if only to avoid 
confusion.  For my specific needs it is always clear when I want a 
rename or a move as the move case must be implemented by a 
copy+verify+delete (so I cannot let the default implementation do the 
move).  If a move accidently occurs when I really wanted a rename it 
would be a bug that needed fixing.  NOCOPY_ALLOWED helps to find those 
bugs instead of it silently doing a potentially very slow move operation.
 
The pitfall of the current moveTo is that it can be lightning fast or 
potentially take hours.  With copyTo I know what I'm getting in to.  
With a renameTo the same thing :)

--John