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.

FTPSclient not working properly on new FTPS server

We will be moving to our own ftps server in the near future from a customer's ftps server. I just tried the existing code but it doesn't work correctly with our new server.
The login seems to work and I can use printWorkingDirectory() and see that I'm in the correct directory on the server. But we can't upload files or list the files in the working directory. listFiles() and printWorkingDirectory() return an empty string or an empty array, although files are in the working directory.
IIRC we had similar issues on the old FTPS server and could fix it by entering passive mode. But neither enterLocalPassiveMode() nor enterLocalActiveMode() work. Also leaving that line out completely doesn't help
The server itself works fine when connecting with FileZilla, so I guess the problem lies within our code but since we don't get an error message it's hard to guess what the problem is.
Here's the version that worked on the old server (using cfscript on Lucee 5.1.2.24):
var oFTPSclient = CreateObject("java", "org.apache.commons.net.ftp.FTPSClient").init("ssl",false);
oFTPSclient.connect( 'our.ftp.server');
oFTPSclient.enterLocalPassiveMode();
oFTPSclient.login( 'user', 'password');
var qFiles = DirectoryList(
path = '/path/to/files/to/upload',
filter = "*.jpg",
listInfo = "query"
);
// Upload files
for( var oFile IN qFiles) {
// Create path to source file
var sSourceFilePath = ExpandPath( oFile.directory & '/' & oFile.name);
// Create java file object
var oJavaFile = CreateObject( "java", "java.io.File").init( sSourceFilePath);
// open input stream from file
var oFileInputStream = CreateObject("java", "java.io.FileInputStream").init( oJavaFile);
// Set file transfer to binary
oFTPSclient.setFileType( oFTPSclient.BINARY_FILE_TYPE);
// store current file to server
oFTPSclient.storeFile( oFile.name, oFileInputStream);
oFileInputStream.close();
}
oFTPSclient.disconnect();
When we try to upload files, the loop finishes, but way to quickly (our connection is rather slow here, so a few megabytes should not be uploaded instantly) and the disconnect() call at the end times out.
Any ideas where to start debugging? Or is my initial assumption that it's a problem with the code wrong and it's a problem with the server and we should rather look into that?
Update:
Due to the length, I have posted FileZilla's verbose log here: http://pastebin.com/b9TfR7cg

NoSuchMethodError for Class File Method toPath()

I'm attempting to copy the file StandardQuestions.csv to a new filename with the following code:
String standardQuestions = "StandardQuestions.csv";
if(new File(standardQuestions).exists()){
try{
Path source = new File(standardQuestions).toPath();
Path dest = new File(filename).toPath();
Files.copy(source,dest);
}
catch(java.io.IOException e){JOptionPane.showMessageDialog(this,"Error: Input/Output exception.");}
}
I get an error thrown on the line Path source = new File(standardQuestions).toPath(); My error message is NoSuchMethodError, method toPath not found in class File. How could the File class not have this method? The program runs correctly on 3-4 machines, but for one user, it always throws this error. Any idea what's causing this? Is there any additional information needed to answer this question?

Since Path and toPath() are relatively recent additions to the Java library (they've been added in Java 7), I'd make sure you are using the same version of Java across the machines.

The first thing that comes up is that one user is running a significantly different version of Java. It might be particularly old or non-standard (GNU Classpath).
Have your user upgrade their Java installation version.

Java file IO and "access denied" errors

I have been tearing my hair out on this and thus I am looks for some help .
I have a loop of code that performs the following
//imports ommitted
public void afterPropertiesSet() throws Exception{
//building of URL list ommitted
// urlMap is a HashMap <String,String> created and populated just prior
for ( Object urlVar : urlMap.keySet() ){
String myURLvar = urlMap.get(urlVar.toString);
System.out.println ("URL is "+myURLvar );
BufferedImage imageVar = ImageIO.read(myURLvar);//URL confirmed to be valid even for executions that fail
String fileName2Save = "filepath"// a valid file path
System.out.println ("Target path is "+fileName2Save );
File file2Save = new File (fileName2Save);
fileName2Save.SetWriteable(true);//set these just to be sure
fileName2Save.SetReadable(true);
try{
ImageIO.write (imageVar,"png",file2save)//error thrown here
}catch (Exception e){
System.out.println("R: "+file2Save.canRead()+" W: "+file2Save.canWrite()+" E:"+file2Save.canExecute()+" Exists: "+file2Save.exists+" is a file"+file2Save.isFile() );
System.out.println("parent Directory perms");// same as above except on parent directory of destination
}//end try
}//end for
}
This all runs on Windows 7 and JDK 1.6.26 and Netbeans,Tomcat 7.0.14 . The target directory is actually inside my netbeans project directory in a folder for a normal web app ( outside WEB-INF) where I would expect normally to have permission to write files.
When the error occurs I get one of two results for the file a.) All false b.)all true. The Parent directory permission never change all true except for isFile.
The error thrown ( java.IO.error with "access denied" ") does not occur every time ... in fact 60% of the time the loop runs it throws no error. The remaining 40% of the time I get the error on 1 of the 60+ files it writes. Infrequently the same one. The order in which the URLs it starts from changes everytime so the order in which the files are written is variable. The file names have short concise names like "1.png". The images are small..less then 8k.
In order to make sure the permissions are correct I have :
Given "full control" to EVERYONE from the net beans project directory down
Run the JDK,JRE and Netbeans as Administrator
Disabled UAC
Yet the error persists. Google searches for this seem to run the gamut and often read like vodoo. Clearly I ( and Java and Netbeans etc ) should have permission to write a file to the directory .
Anyone have any insight ? This is all ( code and the web server hosting the URL) on a closed system so I can't cut and paste code or stacktrace.
Update: I confirmed the imageURL is valid by doing a println & toString prior to each read. I then confirmed that a.) the web server hosting the target URL returned the image with a http 200 code b.) that the URL returned the image when tested in a web browser. In testing I also put a if () in after the read to confirm that the values was not NULL or empty. I also put in tests for NULL on all the other values . They are always as expected even for a failure .The error always occurs inside the try block. The destination directory is the same every execution. Prior to every execution the directory is empty.
Update 2: Here is one of the stack traces ( in this case perms for file2Save are R: True W:True E: True isFile:True exists:True )
java.io.FileNotFoundException <fullFilepathhere> (Access is denied)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212)
at javax.imageio.stream.FileImageOutputStream.<init>(FileImageOutputStream.java:53)
at com.sun.imageio.spi.FileImageOutputStreamSpi.createOutputStreamInstance(FileImageOutputStreamSpi.java:37)
at javax.imageio.ImageIO.createImageOutputStream(ImageIO.java:393)
at javax.imageio.ImageIO.write(ImageIO.java:1514)
at myPackage.myClass.afterPropertiesSet(thisClassexample.java:204)// 204 is the line number of the ImageIO write

This may not answer your problem since there can be many other possibilties to your limited information.
One common possibilty for not being able to write a file in web application is the file locking issue on Windows if the following four conditions are met simultaneously:
the target file exists under web root, e.g. WEB-INF folder and
the target file is served by the default servlet and
the target file has been requested at least once by client and
you are running under Windows
If you are trying to replace such a file that meets all of the four conditions, you will not be able to because some servlet containers such as tomcat and jetty will buffer the static contents and lock the files so you are unable to replace or change them.
If your web application has exactly this problem, you should not use the default servlet to serve the file contents. The default servlet is desigend to serve the static content which you do not want to change, e.g. css files, javascript files, background images, etc.
There is a trick to solve the file locking issue on Windows for jetty by disabling the NIO http://docs.codehaus.org/display/JETTY/Files+locked+on+Windows
The trick is useful for development process, e.g. you want to edit the css file and see the change without restarting your web application, but it is not recommended for production mode. If your web application relies on this trick in the production process, then you should seriously consider redesign your codes.

I cannot tell you what's going on or why... I have a feeling that it's something dependent on the way ImageIO tries to save the image. What you could do is saving the BufferedImage by leveraging the ByteArrayOutputStream as described below:
BufferedImage bufferedImage = ImageIO.read(new File("sample_image.gif"));
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ImageIO.write( bufferedImage, "gif", baos );
baos.flush(); //Is this necessary??
byte[] resultImageAsRawBytes = baos.toByteArray();
baos.close(); //Not sure how important this is...
OutputStream out = new FileOutputStream("myImageFile.gif");
out.write(resultImageAsRawBytes);
out.close();
I'm not really familiar with the ByteArrayOutputStream, but I guess its reset() function could be handy when dealing with saving multiple files. You could also try using its writeTo(OutputStream out) if you prefer. Documentation here.
Let me know how it goes...

How to create a directory with multiple levels in one call in Java using FTP

I am using the FTPClient library from Apache and cannot figure out a simple way to create a new directory that is more than one level deep. Am I missing something?
Assuming the directory /tmp already exists on my remote host, the following command succeeds in creating /tmp/xxx
String path = "/tmp/xxx";
FTPClient ftpc = new FTPClient();
... // establish connection and login
ftpc.makeDirectory(path);
but the following fails:
String path = "/tmp/yyy/zzz";
FTPClient ftpc = new FTPClient();
... // establish connection and login
ftpc.makeDirectory(path);
In that latter case, even /tmp/yyy isn't created.
I know I can create /tmp/yyy and then create /tmp/yyy/zzz, but I can't figure out how to create directly /tmp/yyy/zzz.
Am I missing something obvious? Using mkd instead of makeDirectory didn't help.
Also, is it possible in one call to upload a file to /tmp/yyy/zzz/test.txt if the directory /tmp/yyy/zzz/ doesn't exist already?

You need to do them one at a time, first /tmp/yyy and then /tmp/yyy/zzz. There is no short-cut mechanism for what you want to do.

FTP servers typically only allows you to create 1 level of a directory at a time. Thus you'll have to break up the path yourself, and issue one makeDirectory() call for each of the components.
No.

The FTP protocol doesn't permit this. So no, you can't create a directory with multiple levels in one call.