search for: mucommand

Hi All, In the last few days, I've been working on leveraging a pluggable mechanism that is going to be introduced for muCommander [1] to provide a front-end for libguestfs. I published a video [2] that demonstrates this integration: enabling to browse/upload-to/download-from virtual disks via a file manager with a dual-pane interface. I've followed the guidelines for inspecting the disk's file system(s) I got on I...

...present it to a user on your UI. But if you want to: just check libtsk feature availability before using guestfs functionality (like filesystem_walk) which depends on it. You will always depends on guestfs available on a host system if you don't build and provide your own build alongside with muCommander. And you never know how guestfs was built and what features are available. So you should always check feature availability before using it. Moreover a lot of functionality of libguestfs very depends on a host kernel and available modules. My experience with libguestfs forces me to build it myself...

> Well, I don't need any information about the operating system itself but ideally, when browsing the disk image the user sees the file system(s) as if the user would have connected (e.g., via ssh) to the guest. So let's say that I browse a disk image with two partitions, the root that is mounted to "/" and another one that is mounted to "/boot". I think it makes

...so on. > 4. You can umount current file system when the user goes back to a > very first level (list of file systems). > 5. And you can terminate current libguestfs instance when user goes > out of the current disk image on you UI. About terminating the libguestfs instance, note that muCommander caches the browsed files internally to improve responsiveness. For example, imagine that the user has several open tabs - it makes sense for muCommander to keep their current location cached because of the likelihood the user will switch between those tabs. So I would rather rely on the framework...

Hi, When using the libguestfs-java bindings, java.library.path should point to the place the JNI stuff resides in. In [1] it was suggested to set it to /usr/local/lib but apparently, it is deployed elsewhere in other distributions, right? so I wonder what is the recommended way of setting it in a Java application that could execute on various distributions. Additionally, the libguestfs-java