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

[Salter, Thomas A]

As you thought, I meant getName().  I knew it was there but mixed up with the overloaded getName(index).

-----Original Message-----
From: nio-dev-bounces at openjdk.java.net [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman
Sent: Thursday, December 17, 2009 4:20 PM
To: nio-dev at openjdk.java.net
Subject: Re: NIO2's Path.moveTo(...) needs renameTo(...) aequivalent,or atleast javadoc clarification.

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.