Will it work on Unix?

Question

This Java code displays 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); } 

Answer 1

Short answer: None.

Long answer: Do you have samba installed? Even then you need to establish this share. So it probably won't work.

EDIT

Java delegates the call to the main OS ultimately. Because Unix does not know what the \\SERVERNAME path means, Java does not know what this means. What you need to do to get this to work is to mount the drive explicitly using Samba. Another option, if you are using Ubuntu, is under .gvfs in your home directory. Ubuntu creates a mount for your Samba stocks with which you must have access using Java. If you don't want to rely on external tools, try JCIFS for a solution with pure Java.

Answer 2

No ... Just let the user choose the right path and use the OS-specific file selection dialog.

Answer 3

On my system (Debian Sid with Gnome 2.30 Desktop) I need to select "smb: /// server / Shared / ..." to achieve the same behavior. I think that GVFS (Gnome virtual file system) using smbfs drivers handles a real connection in the background ...

Answer 4

No, because this is a UNC path that is windowed.

Are you trying to access share Windows from unix? Then look through jcifs .

Answer 5

The counter question I get when I see this is: “Why do you want to hardcode the path in your application?”

Even if it were just for example, and you intend to load the path from the properties file or something else, I still think that you are mistaken here.

First of all, you will want to avoid absolute paths such as the plague. Relative paths like approx. You can use slash characters ('/') in hard path encodings, they will work on both Windows and Linux / Mac. Mostly all platforms.

Secondly, why use the paths at all? This is the internet age. Use URL! file: The URL will do the same as the file paths, but using the URL, the application can also accept resources from other sources, such as websites and FTP.

Third, avoid the File class. If you come up with a good way to do this, you are completely made of wood. Use the URL along with getResource and getResourceAsStream, and your application will work regardless of platform and across network boundaries over the Internet.