Let me share my thoughts. > However, as one can see in the video, it takes a pretty long time to inspect > the disk (in order to find the operating system) and to mount the file > systems.
Do you really need to inspect disk image BEFORE mounting file system(s)? You can do inspection on demand if you want/need to provide some metadata about installed OS etc. And definitely inspection might take some time. Pay attention that it is better to provide all images to libguestfs if original installation was spread across multiple disks. And while it is not strongly required but is good idea to provide all disk images in the same order. I think you can use list-filesystems, mount, ll and friends to navigate file system on demand as user drills down disk image(s). E.g.: 1. User: selects disk image, double-click. You: launch libguestfs instance, call list-filesystems and display them. 2. User: selects some file system, double-click. You: mount file system, call ll (or friends) and display top-level file system hierarchy. 3. User: selects directory, double-click. You: call ll (or friends) to discover and display next level. And 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. Again, pay attention that with LVM, Windows dynamic disks, MD arrays you might need to provide all involved disk images to a guestfs to make things to work as expected. Another thing to keep in mind that original disk image might be altered if you launched guestfs instance in RW mode even it seemed you/user didn't make any modifications. That is because some file systems will apply journal on mount. > So it takes me back to the filesystem_walk function as I read in [4] that it > allows inspecting the metadata without mounting the disk partition(s). > Unfortunately, I didn't manage to try that function due to the following > error I get when trying to use it (tried on Fedora 28 & 29): > > Exception in thread "main" com.redhat.et.libguestfs.LibGuestFSException: > internal_filesystem_walk: feature 'libtsk' is not available in this > build of libguestfs. Read 'AVAILABILITY' in the guestfs(3) man page for > how to check for the availability of features. > at com.redhat.et.libguestfs.GuestFS._filesystem_walk(Native Method) > at com.redhat.et.libguestfs.GuestFS.filesystem_walk(GuestFS.java:6010) > at test.Main.main(Main.java:27) > > Is that right that the filesystem_walk doesn't require mounting the disk > partition(s)? If that's true, can we publish a version that supports that in > the Fedora repo? Do you think filesystem_walk will help you? It might take even longer. I think it will return you a list of ALL the files and directories. And you have to build directory tree yourself to 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. I also build my custom guestfs appliance to not depend on a host kernel etc. You can consider using mount_local but that is another story... -- Mykola Ivanets _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
