We Keep Coding

Java can't access file on local path

Asked this question, having already tried possible solutions in other questions here on stack but that didn't allow me to fix the problem.
As in the title, I have created a java utility with which I have to perform operations on text files, in particular I have to perform simple operations to move between directories, copy from one directory to another, etc.
To do this I have used the java libraries java.io.File and java.nio.*, And I have implemented two functions for now,copyFile(sourcePath, targetPath) and moveFile(sourcePath, targetPath).
To develop this I am using a mac, and the files are under the source path /Users/myname/Documents/myfolder/F24/archive/, and my target path is /Users/myname/Documents/myfolder/F24/target/.
But when I run my code I get a java.nio.file.NoSuchFileException: /Users/myname/Documents/myfolder/F24/archive
Having tried the other solutions here on stack and java documentation already I haven't been able to fix this yet ... I accept any advice or suggestion
Thank you all
my code:
// copyFile: funzione chiamata per copiare file
public static boolean copyFile(String sourcePath, String targetPath){
boolean fileCopied = true;
try{
Files.copy(Paths.get(sourcePath), Paths.get(targetPath), StandardCopyOption.REPLACE_EXISTING);
}catch(Exception e){
String sp = Paths.get(sourcePath)+"/";
fileCopied = false;
System.out.println("Non posso copiare i file dalla cartella "+sp+" nella cartella "+Paths.get(targetPath)+" ! \n");
e.printStackTrace();
}
return fileCopied;
}

Files.copy cannot copy entire directories. The first 'path' you pass to Files.copy must ALL:
Exist.
Be readable by the process that runs the JVM. This is non-trivial on a mac, which denies pretty much all disk rights to all apps by default until you give it access. This can be tricky for java apps. I'm not quite sure how you fix it (I did something on my mac to get rid of that, but I can't remember what - possibly out of the box java apps just get to read whatever they want and it's only actual mac apps that get pseudo-sandboxed. Point is, there's a chance it's mac's app access control denying it even if the unix file rights on this thing indicate you ought to be able to read it).
Be a plain old file and not a directory or whatnot.
Files.move can (usually - depends on impl and underlying OS) usually be done to directories, but not Files.copy. You're in a programming language, not a shell. If you want to copy entire directories, write code that does this.

Not sure whether my comment is understood though answered.
Ìn java SE target must not be the target directory. In other APIs of file copying
one can say COPY FILE TO DIRECTORY. In java not so; this was intentionally designed to remove one error cause.
That style would be:
Path source = Paths.get(sourcePath);
if (Files.isRegularFile(source)) {
Path target = Paths.get(targetPath);
Files.createDirectories(target);
if (Files.isDirectory(target)) {
target = Paths.get(targetPath, source.getFileName().toString());
// Or: target = target.resolve(source.getFileName().toString());
}
Files.copy(source, target, StandardCopyOption.REPLACE_EXISTING);
}
Better ensure when calling to use the full path.

Covert Symbolic Link folder to Hard Link Folder

I created a symbolic Link folder which contains list of files. Is there any way to convert the Symbolic Link to HardLink using java?

To create a hard link using java, you can use :
Path newLink = ...;
Path existingFile = ...;
try {
Files.createLink(newLink, existingFile);
} catch (IOException x) {
System.err.println(x);
} catch (UnsupportedOperationException x) {
// Some file systems do not
// support adding an existing
// file to a directory.
System.err.println(x);
}
So, in your case newLink should be the oldSymbolicLink that you've created, and the existingFile represent its target.
To get the target of a symbolic link you may use
Files.readSymbolicLink(oldSymbolicLink));
Oracle Doc: Links, Symbolic or Otherwise

The Java doc as pointed out by others says that hard links on directories cannot be created. So, instead of telling you how to create hard link to directories, I am going to explain why you cannot create hard link on directories.
Hardlinks are on directories can cause loops when you are trying to traverse the directory tree.
For example if you have a directory /foo/bar and a symbolic link /foo/bar/baz pointing to ../bar, when you try to traverse this tree, you will run into an infinite loop.
/foo/
/foo/bar
/foo/bar/baz
/foo/bar/baz/bar
/foo/bar/baz/bar/baz
...
Now, if baz is a symlink to ../bar, it is simple to fix by unlinking baz using the unlink(2) system call (because unlink does not follow symlinks). However, if baz was a hard link, it would have been much harder (no pun intended) to fix this. In the book "Advanced Programming in Unix Environment", Stephen Rago notes that Rich Stevens corrupted his file system while trying this experiment (and fsck was unable to recover it)

Whether a file is symbolic link or not in Java [duplicate]

In a DirectoryWalker class I want to find out if a File instance is actually a symbolic link to a directory (assuming, the walker walks on UNIX systems). Given, I already know the instance is a directory, would the following be a reliable condition to determine the symbolic link?
File file;
// ...
if (file.getAbsolutePath().equals(file.getCanonicalPath())) {
// real directory ---> do normal stuff
}
else {
// possible symbolic link ---> do link stuff
}

The technique used in Apache Commons uses the canonical path to the parent directory, not the file itself. I don't think that you can guarantee that a mismatch is due to a symbolic link, but it's a good indication that the file needs special treatment.
This is Apache code (subject to their license), modified for compactness.
public static boolean isSymlink(File file) throws IOException {
if (file == null)
throw new NullPointerException("File must not be null");
File canon;
if (file.getParent() == null) {
canon = file;
} else {
File canonDir = file.getParentFile().getCanonicalFile();
canon = new File(canonDir, file.getName());
}
return !canon.getCanonicalFile().equals(canon.getAbsoluteFile());
}

Java 1.6 does not provide such low level access to the file system. Looks like NIO 2, which should be included in Java 1.7, will have support for symbolic links. A draft of the new API is available. Symbolic links are mentioned there, creating and following them is possible. I'm not exactly sure that which method should be used to find out whether a file is a symbolic link. There's a mailing list for discussing NIO 2 - maybe they will know.

Also, watch out for file.isFile() and file.isDirectory() both returning results based on the resolved file and therefore both returning false when file refers to a symlink where the target doesn't exist.
(I know this isn't a useful answer in itself but it tripped me up a couple of times so thought I should share)

It looks like getCanonicalPath() can do other things that might make it different from the absolute path.
This method first converts this pathname to absolute form if necessary, as if by invoking the getAbsolutePath() method, and then maps it to its unique form in a system-dependent way. This typically involves removing redundant names such as "." and ".." from the pathname, resolving symbolic links (on UNIX platforms), and converting drive letters to a standard case (on Microsoft Windows platforms).
But it might work for the vast majority of your use cases; your mileage may vary.

If you are already coding something specifically for *nix, then you could do a shell command from Java like this:
Process p = Runtime.getRuntime().exec(new String[]{"test", "-h", yourFileName});
p.waitFor();
if (p.exitValue() == 0)
System.out.println("This file is a symbolic link");
else
System.out.println("This file is not a symbolic link");
That's very specific to *nix, but it does at least work.

Sorry to reply to such an old post, but I was looking for a solution for Windows systems some time back, and some of the previous answers didn't work out for me. If you're not concerned with cross platform compatibility and only need a solution for Windows, the following technique worked well for my purposes.
File f = new File("whatever file or folder");
if (f instanceof ShellFolder) {
ShellFolder sf = (ShellFolder)f;
if (sf.isLink()) {
// Your code when it's a link
}
}

I thought I would share some good fortune I had in dealing with this issue. I am using JDK 1.6.0_23 and so I cannot benefit from NIO2. I am building and running on Windows 7 /x64 ONLY so mileage may vary in other environments. Unfortunately, other solutions here did not work for me in avoiding NullPointerExceptions caused when attempting to traverse a junction (probably because junction != symlink....). While I am not constrained by JDK version, I decided to keep at the problem for a bit longer.
I had this code which would cause a NullPointerException if used on a symbolic link or when encountering the 'System Volume Information' directory. (Note, traverseItem.f() returns an object of type java.io.File)
if (traverseItem.f().isDirectory) {
for (File item : traverseItem.f().listFiles()) {
So, it is supposedly a directory but calling listFiles() on it causes an NPE. What to do? I spied the list() method and wondered if it would exhibit the same behavior. What I discovered was the following:
Calling list() on a File describing an empty folder returns a String[] array of length zero. However, calling list() on a File describing a junction which would otherwise crash from listFiles() returns null
I was able to avoid the NullPointerExceptions by adding the following test before calling listFiles()
String[] contents = traverseItem.f().list();
if (contents != null) { //Non-traversible if null, possibly junction or ???
It remains to exhaustively test all cases of junction, symbolic link, hard link, and dare I mention it, shortcut, but this may help some.

java listfiles hanging on files with bad characters

I have this code that lists all the files in a dir:
File d = getRootDir(cId);
return d.listFiles(new FilenameFilter() {
public boolean accept(File dir, String name) {
return name.endsWith(FILE_EXTENSION);
}
}
It hangs because, the dir got corrupted and has a file name with invalid chars. Is there an alternate way to do this, so that i can get the list of files and not hang?
Thanks.

Personally whenever I do file operations I will use apache Commons-io. I find the API much easier to work with than Java's own while still using standard File object.
That said I do not know if switching will make it list without hanging.
Insert a logging statement in your accept method. I'd recommend a logging library but a simple
System.out.println("Checking " + name + " in " + dir);
Should suffice.
You will now where it is hanging but probably not why. Perhaps it is not hanging for the reason you think it is, the log statement will give you more information on this. You can dig deeper by trace debugging the code though for this you will probably need to download the source code of the JDK.
What is the illegal character you have in your file that is causing problem ?
Also, a second look here at your code. The file name contains the file and extension. By checking with endsWith you risk getting false positive where a file may not have an extention or a different extention. For example :
FILE_EXTENSION = "log";
The following files will trigger though it will not be what you want.
totolog
toto.totolog
You can prepend the . before, if you have full control (not user defined configuration) then it will do but a cleaner solution is to extract the extension and compare that. A simple call to FilenameUtils.getExtension will do the trick.

Have you tried d.list() and interating over that to determine your accept? The problem might be inside FilenameFilter and not the actual interating over the file list.

Are you on Windows? Have you tried chkdsk? (however you get to that these days).

Why would a file rename fail in java

I have the following snippet of java code:
File directoryToMoveTo = new File(file.getParent()+"_TEMP");
boolean success = file.renameTo(new File(directoryToMoveTo,file.getName()));
if (!success){
logger.warn("Failed to move [%s] to temp Directory.");
}
file is passed in as an argument to the method and is one of an array of files obtained like this:
File[] files = directory.listFiles(new FilenameFilter() {
#Override
public boolean accept(File dir, String name) {
logger.debug(String.format("Testing file [%s]",name));
boolean passed = name.endsWith(getFileDescription().getFilePattern());
logger.debug(String.format("Passed [%s]",passed));
return passed;
}
});
Why would success by false in the first snippet?
I tried this code in isolation on a different file and it seems to work.

Obvious situations:
the target file already exists
the target directory doesn't exist
the target directory is on a different file system
the target directory is read-only (or at least, the current user doesn't have write access)
I'd expect those to at least potentially fail (the JavaDoc explicitly says that a lot of this behaviour is OS-dependent) - have you tried them?

I found the problem. It was because the directory I was copying to didn't exist.
surrounding with this if statement worked:
if (directoryToMoveTo.exists() || directoryToMoveTo.mkdir()){ }

Original doesn't exist?
Already a file at the destination path?
Destinatination path doesn't exist?
Source file read only?
Just a few ideas

I can think of:
target directory does not exist
not enough access rights (target directory write protected)
not enough free space on target directory's data partition
...

The file may be still open, even though you closed it: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6266377

Not to forget you might not be allowed to write/change/rename a file.
Hardly ever a problem in windows, but common in Unix environments.

To find the exact reason why it is not working you could System.out.println these paths and try to move them from OS level. That would give the good indication why is it not working.