What's the best way of processing *ix file path strings when running on Windows?
If I just use Paths.get() it invokes Filesystem.getDefault() which ends up processing it like a Windows path. The parsing seems to work in my tests but they're pretty rudimentary, and of course toString uses the wrong path separator.
Can I manually load up the LinuxFileSystem somehow? Or should I use the commons-io parser instead?
Can I manually load up the LinuxFileSystem somehow?
I doubt it, because one JDK distribution is oriented either to Unix or either to Windows. The only chance I think of is that you look for an open source distribution of some UnixFileSystemProvider and import into your application's runtime.
But even in that case, I have my doubts it will work 100%, because a FileSystemProvider class deals with low-level details from the underlying OS - not just path separators, so there is a risk that it won't be compatible over a Windows filesystem.
Looks like #Little Santi's comment on the question is in fact the answer. If I run:
for (FileSystemProvider provider: FileSystemProvider.installedProviders()) {
System.out.println(provider.getClass().getName());
}
I get:
sun.nio.fs.WindowsFileSystemProvider
com.sun.nio.zipfs.ZipFileSystemProvider
If I interpret this correctly it means I can't use the LinuxFileSystem path methods under Windows but should use commons-io instead.
Related
I need to parse the configurations defined in a Vagrantfile written in Ruby and use the settings elsewhere in my java code. Tried exploring jRubyParser but din't come across any documentation that defines it's use.
Cloned the Vagrant repo locally, but browsing through the code does not help either as I don't have prior experience with Ruby. How would Vagrant be reading the configurations defined in the file ? Any inputs ?
Vagrantfile is a regular Ruby script, i.e. it's meant to be interpreted by Ruby intepreter more than read as a configuration file.
To make things harder, some configuration options aren't declared as top level variables in Vagrantfile, but rather as properties of object in some function calls (like "config.vm.provider".
Depending on how complex your configuration is, I would consider just reading the file line by line and do regular expression matching to get variables I'd need. Not the most elegant solution, but probably way quicker too implement than alternatives.
Also, if your provider is always the same, say VirtualBox, maybe you could get some of your configuration from there. In that case, you would just need to read file located somewhere in "VirtualBox VMs" directory (on Mac, it's in "$HOME/VirtualBox VMs"). It's an XML file, so you could use one of the Java XML parsers to get what you need.
Is there any mechanism to get and set the file/directory permissions?
For example, I want to show the permisssions of a file in a shell way:
-rwxr-xr--
Is it possible to do this using Java?
I know that there are some methods in the File class to know if the file canExecute, canRead and canWrite, but AFAIK this info is for the current user only. I need to know the whole octal number, for example 755, so I need to get it from the user, from group and from others.
I know that Java7 brings Posix operations, but how could do this using a smaller JRE?
I would like not to use a command like ls, or chmod.
If you can use external libraries, there are several:
JPosix
Posix for java
jnr-posix
If an entire library seems a hassle, creating a JNI wrapper that calls the lstat C function and returns the access mode takes you about 10 minutes. Here's a tutorial that creates such a wrapper for the isatty and ttyname functions.
As you say, in Java7, the JVM supports it, so you have a guarantee that this can be done portably in all OSs (because the JVM implementation takes care of it). Under Java7, you'd have to use a native library per OS you want to support. This is potentially even dirtier than executing chmod
I'm not sure if what I'm asking is possible, but I would like to do the following:
When a file is created in a certain folder (Windows), my program should respond. I'd like to let Windows call a callback method when a file is created.
Another option is of course just use a loop and constantly check if a new file is in the folder, but I'd like to know it instantly, so a callback method would be much more efficient.
Is this possible? The language is not important, although Java is preferred.
With Java nio 2 (available in Java 1.7 +), you can "watch" a directory and get notified when that directory changes.
The method proposed in the tutorial linked above uses the WatchService API.
Commons IO contains a FileAlterationListener wich has a onDirectoryChangemethod. Can be an alternative if Java 1.7 is not available.
If you are not bound to Java, then you could use very convenient FileSystemWatcher in C# or VisualBasic. It will allow you to watch all kinds of events which can occur in folder and it's quite easy to implement it.
I am currently writing a program in JAVA that examines the behavior of external executable. One of the requirements is to observe the file operations of the external executable in real time (check if the executable creates/ deletes/modifies any file). I tried to find a suitable API in java to help me do this though it was not possible to find one. I have found the Class FileAlterationObserver which is not suitable for my program since you have to specify manually all the directories you want to monitor.
I was wondering if any of you knows a good API to use?
Thanks for your time in advance.
Without java, you could use the linux lsof command to list the open files in the system. Alternatively, and with Java, you can use libnotify, but you will need to specify the folders. I can't see any other way of doing this with pure java.
EDIT #Keppil linked you to the file change notification API that looks way more suitable than libjnotify. I wasn't aware it existed!
are there any things that once can do ignorantly that can prevent a java web application from being cross platform? (windows/linux/mac)
Tools I am planning to use are java/spring framework/hibernate
Hard-coding file separators/paths.
Using native libraries.
Using Runtime.exec()
Using sun.* classes (this may cause portability issues with non-Sun JVMs).
not honoring case-sensitivity in filesystem
Using system default character encoding for input/output when inappropriate
In addition to what Dan Dyer said:
calling executables by a fixed path or of a fixed name
assuming a certain shell command syntax will work properly (eg 2>&1 or something)
deleting or renaming a file that some other process (or the same one!) might have open
Making assumptions about the working directory (eg using relative paths to load resouces from the file system)