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

[Alan Bateman]

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);
    }

> Likewise, a variant of subpath that returns just the last node would be useful, rather than writing:
>         int lastNode = file.getNameCount() - 1;
>         Path last = file.subpath(lastNode, lastNode);
>   
Did you mean subpath(lastNode, lastNode+1)? That would return the 
filename and getName() already does this (just mentioning in case you 
missed it or I mis-understood the intention).

> :
>
> 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)

> Or at least add clarification in javadoc? (Which is far less appropriate, an API has to "talk" to the user by classes and methods names)
>
> I'm afraid, most people will start using File.renameTo(File newFile), which would fail to handle symbolic-link correctly.
> Or, what is even worse, people will try to concat some strings, and create a destination Path of the result.
>
> Something like:
>     Path newName = Paths.get(name.getParent().toString()+File.pathSeparator+"newName");
>
> While someone would even do:
>     name.getParent().toString()+"\\"+"newName", or name.getParent().toString()+"/"+"newName"
>   
The resolve method is the easiest way to combine or join paths, so the 
above can be replaced with:
  name.getParent().resolve("newName");

-Alan.