I\'m trying to list a directory\'s contents, and rename certain files.
public void run(String dirName) {
try {
File parDir = new File(dirName);
You need to create your new File
object with the full pathname of those files. So
String name = f.getName(); // gets the name without the directory
should likely be:
String name = f.getAbsolutePath();
(your search/replace may need to change)
The problem is that f.getName()
returns the last name component of the path that is represented by f
. You then massage this String and turn it back into a File
. But the File
now represents a path relative to the current directory, not the directory containing the original path.
As a result your code is actually attempting to rename the files from dirName
into the application's current directory. That could fail because files already exist in the current directory with those names, or because the dirName
and the current directory are in different file systems. (You cannot rename a file from one filesystem to another ... you have to copy it.)
Please note that a File
in Java represents a pathname, not a file or a folder. In your code, the f
objects are the pathnames for file system objects (either files or folders) in the directory denoted by the String dirname
. Each of these f
objects will have a directory part.
There is more than one way to fix your code; for example
name = f.getName()
to name = f.toString()
new File(subbedName)
to new File(f.getParentFile(), subbedName)
I have an alternative / additional theory.
The pathname of the file containing the \uFFFD
character is coming out as "mojibake"; i.e. the kind of garbled text that you get when you display encoded text using the wrong encoding. And since we are seeing 3 characters of garbled text, I suspect that it is attempting to display the UTF-8 rendering of \uFFFD
as Latin-1.
So my theory is that the same think is happening when the File.renameTo
method is converting f
to the form that it is going to provide to the system call. For some reason that is no clear to me, Java could be using the wrong encoding, and as a result producing a "name" for the original file that doesn't match the name of the file in the file system. That would be sufficient to cause the rename to fail.
Possibly related questions / links:
f.getName();
only returns the name of the folder, not the full path. So subbedName
becomes a relative path file. Try something with f.getCanonicalPath()
instead.