I am sure this is a relatively simple question, and I actually think it may be more of a problem with Windows than with Java.
I have a method for copying a file to a new directory, which takes two File objects, a File created with the path of the original, and a File created with the desired path of the copy. I am sure that the method works because I have used it to successfully copy a file onto my Desktop.
However, using my actual desired path creates an error:
java.io.FileNotFoundException: PATH (The system cannot find the path
specified)
Where the PATH is the path that I am attempting to use.
Here is my guess:
I am making this program for use on another machine. As such, the path that I am trying to use is:
C:\Users\XXXXXX\rest_of_path\filename.file
where XXXXXX is the primary user on the machine which I am writing the program for.
This directory exists on my system, but XXXXXX is not a user on my system. So I am guessing that Windows is causing a problem because of that.
I'm now changing my code to use a solution which depends on the machine, and is not hardcoded (System.getProperty).
However, I'd really like to know why this problem is occurring, from an academic standpoint, as a Windows and Java user.
Thanks in advance.
EDIT: accidentally used forward slashes when I meant double backslashes. To ensure that it was not a spelling error, I simply copied the directory using windows, and pasted it into my program (then doubled up on the backslashes).
EDIT: several users have suggested something which is far more clean than what I am trying to do in the first place. I'm leaving this question open because I'm curious why it is not working.
EDIT: I used the solution above and I'm completely happy with it. I still don't know why Windows will not allow me to access the original path, but I guess I really don't care at this point. Thanks, everybody!
In java, and generally most programming languages, you don't always have to provide the exact directory of your file. Although it would be nice to see the code you're using to get the file, I'll provide how it can be done.
I'm assuming you aren't using new File("file.txt") because that retrieves files from the folder your program is in, and doesn't require an entire address like C:\...\...\.... You certainly don't want to use an entire address because different operating systems use different paths, obviously.
The best you can do is put your files and requested folders somewhere relative to your program is (whether it's class files or a .jar file).
But with Windows you can be sure that with System.getProperty("...") you can retrieve directory URLs as relative paths for your files/folders.
Documentation on System.getProperty here: http://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
I may not have helped or answered your question at all. But hopefully you'll find a solution.
Related
I am maintaining a Spring Boot project. There is this code:
BufferedReader reader = new BufferedReader(new FileReader("./setting_mail_sender.txt"));
Where should the file be located in this case?
In 'the current working directory'. And where is that? Who knows!
Whomever wrote that code messed up. It's not a good idea to use the CWD for anything in any java code unless you specifically know you want it. And generally, that's only the case when you're writing command line tools in the vein of the various tools you find in your average linux distro's /bin dir - a rare occurrence, given that the JVM isn't really designed for that kind of thing.
There are 3 different best practices for 'data files' depending on the nature of the data:
Static, unchanging data - as much part of your app as your class files are. These should be loaded with MyClass.class.getResource("name-of-resource.txt") and shipped the same way your classes are. For example, inside the jar file.
Config files. These should usually be in System.getProperty("user.home") - the user's home dir; /Users/yourusername on macs, /home/yourusername on linux, C:\Users\YourUserName on windows. Best practice is to ship a 'template' version of the settings file if relevant in the jar file, and upon detecting that there is no config file present at all, to write out the template (and you load the template in via MyClass.class.getResource). If a template is not a good idea, something in a similar vein. Bad practice is to have the installer do this, and have your app be broken or leave the user having to peruse complex documentation to (re)create the config file. A different way to do it right is to have a config page in your app (a window, menu bar setting, web app thing - something with a user interface) where you can change settings and the config file is simply the way you store that data.
Changing data files. For example, you ship H2 (an all-java database engine) with your app and it needs to write its database file somewhere. This is a bit tricky; user home is not the right place for such data files, but you can't really 'find' the dir where your app is installed either. Even if you can, on non-badly-designed OSes, apps usually cannot (and should not!) be able to write to that location anyway. The location where this data is stored should definitely be configurable, so one easy way out is to require that the user explicitly picks a place. Otherwise I'm afraid you're stuck having to write per-OS code - find /Users/myusername/Library/Application Support/yourappname on mac, which is the right place. As far as I know there is no library to do this right.
None of them involve 'require that the user start the app with the right CWD'. There are good reasons for that: It can be hard to configure, and it's not something users think of to configure. For example, when setting up a java app as a recurring task in windows, you can configure the working dir for such a process, but it's not something that's usually considered as crucial configuration. When running a java app from the command line, who knows what the working dir is. You'll end up with an app that usually works, except in some circumstances when it magically doesn't, and most of your users have no idea that the difference between the magic run that works and the one that does not, is the directory they were in when they started the java app.
If you can edit that code, do so - figure out which of the 3 different kinds of data this is about (sounds like the second bullet: Config stuff, so should be in user home, and the app's name should be part of the file name) - and fix it. for example, that should be:
try (var in = Files.newBufferedReader(Paths.get(System.getProperty("user.home"), "myapp-mail.conf")) {
}
This solves a whole bunch of problems:
Uses try-with to avoid resource leakage.
Reads from user.home, avoiding current working directory as relevant setting.
Actually uses UTF-8 encoding (whereas your code will, at least until java 17, do 'platform default'. It's somewhat unlikely you want that, as it means your config file is not portable; copying it from one computer to another may break things. You presumably don't want this.
If errors occur, the error messages are improved (one of the downsides of the 'old' file API).
If you can't change this code, figure out what the CWD is; put the files there, and ensure that, however you start this spring boot project, you always start it from that directory. If you can't change this code but you can run some code in that JVM, you can print it: System.out.println(Paths.get(".").toAbsolutePath()) will show it to you.
my program on startup will:
1. search for a file
2. read the file
3. and set a string to the files contents
But the way ive done it it will only work if they have the exact path that i am hard coding in.
i want the path to adapt to other computers. I think i should use the Path class but ive just heard about that so not sure where to go.
basically i want it to search for a file on any users desktop, and if its not there make it.
if you need some code to clarify i can post it just let me know
I could think of two options.
You can simply specify a file name such as "myFile.txt", so the program will search this file in its program/project folder.
If it does not exist you can write the code to create it in the program folder, instead of hard coding any absolute path.
Else, you can try using the javax.swing.JFileChooser class to pop up an Open and Save dialog box.
This will give the end-user the freedom to select any file for reading and writing.
I found below two articles with some example on how to use the class. Please refer them for more information.
https://www.codejava.net/java-se/swing/show-save-file-dialog-using-jfilechooser
How to "Open" and "Save" using java
Thanks.
You can use the path "./yourfile.txt". It will search for "yourfile.txt" in the directory ".". That means the project's current directory. Maybe it can help you.
Linux Api has O_TMPFILE flag to be specified with open system call creating unnamed temporary file which cannot be opened by any path. So we can use this to write data to the file "atmoically" and the linkat the given file to the real path. According to the open man page it can be implemented as simple as
char path[1000];
int fd = open("/tmp", O_TMPFILE | O_WRONLY, S_IWUSR);
write(fd, "123456", sizeof("123456"));
sprintf(path, "/proc/self/fd/%d", fd);
linkat(AT_FDCWD, path, AT_FDCWD, "/tmp/1111111", AT_SYMLINK_FOLLOW);
Is there a Java alternative (probably non crossplatform) to do atomic write to a file without writing Linux-specific JNI function? Files.createTempFile does completely different thing.
By atomic write I mean that either it cannot be opened and be read from or it contains all the data required to be writted.
I don't believe Java has an API for this, and it seems to depend on both the OS and filesystem having support, so JNI might be the only way, and even then only on Linux.
I did a quick search for what Cygwin does, seems to be a bit of a hack just to make software work, creating a file with a random name then excluding it only from their own directory listing.
I believe the closest you can get in plain Java is to create a file in some other location (kinda like a /proc/self/fd/... equivalent), and then when you are done writing it, either move it or symbolic link it from the final location. To move the file, you want it on the same filesystem partition so the file contents don't actually need to be copied. Programs watching for the file in say /tmp/ wouldn't see it until the move or sym link creation.
You could possibly play around with user accounts and filesystem permissions to ensure that no other (non SYSTEM/root) program can see the file initially even if they tried to look wherever you hid it.
This Java code lists files in a directory on a Windows shared drive. Will it work correctly on a Unix system?
File directory = new File("\\\\server/Shared/stuff/mystuff");
for (File file: directory.listFiles()) {
System.out.println(file);
}
Short answer: No.
Long answer: Do you have samba installed? Even then you need to mount the the share. So it probably won't work.
EDIT
Java delegates the call to the underlying OS eventually. Since Unix doesn't know what the \\SERVERNAME path means, Java doesn't know what it means either. What you have to do, to get this to work is mount the drive explicitly using Samba. Your other option, if you are running Ubuntu, is look under .gvfs in your home directory. Ubuntu creates a mount there for your Samba shares, which you should be able to access using Java. If you don't want to rely on external tools, try JCIFS for a pure-Java solution.
No...
Just let the user select the right path and use an OS dependent file-selection dialog.
On my system (Debian Sid with Gnome 2.30 Desktop) I have to select "smb:///server/Shared/..." to achieve the same behaviour. I think, that GVFS (Gnome Virtual File System) using smbfs drivers handles the real connection in the background...
No, as that is a UNC Path, which is a windowsism.
Are you trying to access a windows share from unix? Then have a look at jcifs.
The counter question I get when seeing this is: "Why would you want to hard-code a path in your application?"
Even if it was just for the example and you intend to load the path from a property file or anything, I still think you are on the wrong track here.
First of all you will want to avoid absolute paths like the plague. Relative paths are sort of ok. You can use slash ('/') characters in paths hardcoded, it will work on both Windows and Linux/Mac. Basically all platforms.
Second of all, why use paths at all? This is the internet age. Use URL's! file: URL's will accomplish the same thing as file paths, but using URL's make your app accept resources from other sources such as web sites and FTP as well.
Third of all, avoid the File class. If you invent a good way to do that, you are out of the woodworks completely. Use URL's together with getResource and getResourceAsStream and your app will work platform independent and across network boundaries over the internet.
Is there a way to search an entire computer for a String value representing a file name in Java? This would be without knowing the names of the drives on the computer.
You can iterate through the file system by looking at file names, getting the contents if it's a directory, etc. recursively.
If the sticking point is how to get the drives on the computer, look at the File.listRoots() function to get a list of the drive letters.
ETA:
To be absolutely safe, you'll want to include some limits on recursive processing. It's possible to have loops in the file system with symbolic links and such (especially in LINUX/UNIX, but third party tools can enable this in Windows as well).
To make sure you don't get into a loop when dealing with symbolic links, use the File.getCanonicalPath methods to get the "real" path for the directory and keep track of all visited canonical paths. You could also use getCanonicalFile and keep track of all the files, but that's probably not needed unless you really want to avoid the occasional instance where you'll process the same file twice.
You can use the File object to determine whether you are looking at a file or a directory:
File file = new File("/"); //root
Then as you are recursing (or iterating depending on your preference) you have a simple check:
if(tempFile.isDirectory())
//do recursive call on that directory
else
//perform check on file name
Also not forget exceptions in recursive processing. Some folders may not be accessible due to access right restrictions. Also, the Windows system folder "System Volume Information" cannot be entered in Windows Explorer, so I suppose it will throw an exception if you try to get inside programmaticaly.
You can use a recursive call through the entire file system: You can use the following methods of java.io.File:
listRoots(): list the root files (In Windows it's the drives, on Mac OS X and linux it's '/').
listFiles(): list the enclosing files of a directory