Umview starts the first process running inside the (partial) virtual machine. This process and all its offspring run under the control of umview.
$ umview xterm
starts an xterm running inside the virtual machine. It is possible to use rxvt or bash instead of xterm.
Before loading any module umview does nothing. Processes running inside the umview machine behave in the same way of all the others processes.
Umfuse is the user-mode implementation of fuse. By using umfuse users can mount file system images as users (not root) inside the virtual machine.
$ mkdir /tmp/mnt $ ls /tmp/mnt $ um_add_service umfuse $ mount -t umfuseext2 -o rw+ ~/tests/linux.img /tmp/mnt $ ls /tmp/mnt bin boot etc lib lost+found mnt proc sbin tmp usr
The example above shows how to mount an ext2 file system. Please note the rw+ option: umfuseext2 is already experimental thus we asked users to confirm the mount in read write mode using this special option. Keep backup of your data before using umfuseext2 support on valuable data. Trying to issue the latter command ls /tmp/mnt from a shell running outside the virtual machine gives different output (an empty dir in this scenario).
In the same way umfuse provides its modules for iso9660 and fat file systems.
$ mount -t umfuseiso9660 image.iso /tmp/mnt1 $ ls /tmp/mnt1 [contents of the cdrom image] $ mount -t umfusefat -o ro image.fat /tmp/mnt2 $ ls /tmp/mnt2 [contents of the fat image]
Iso module uses libcdio/libiso9660 libraries, it provides all the extensions (joliet/rock ridge) provided by the underlying libraries. Iso module mounts compressed-iso images.
Fat library has been created within the project. It supports FAT12, FAT16 and FAT32 images. Fusefat uses our libfat and requires an access mode option: either ro or rw+. rw+ is not automatic because the module is already experimental so it is suggested to backup your valuable data before opening an image in read/write mode.
Third parties fuse/umfuse modules
Umfuse is source compatible with fuse: it means that all the modules designed for umfuse can be compiled as fuse modules and viceversa all fuse modules can be recompiled for umfuse with one exception. Fuse modules are usually designed to manage just one mount operation (the mount operation by fuse of two partitions of the same kind are managed by two separate processes). As a result umfuse modules derived from a umfuse re-compilation of fuse modules usually handle just one mounted partition.
We have tested sshfs and encfs. Umfuse corresponding modules have been named umfusessh and umfuseencfs respectively.
$ um_add_service umfuse $ mount -t umfusessh -o no_readahead remote_machine:/ /tmp/mnt $ ls /tmp/mnt [ls of remote_machine root dir] $ umount /tmp/mnt
$ um_add_service umfuse $ mkdir /tmp/clean /tmp/enc $ mount -t umfuseencfs -o pre="" /tmp/enc /tmp/clear [on the window where umview started from, there are some dialogues about the password of the encrypted directory] $ echo ciao > /tmp/clear/ciao $ cat /tmp/clear/ciao ciao $ ls /tmp/enc 8OHYnVwB4Hj4t, $ cat /tmp/enc/8OHYnVwB4Hj4t, qH4'�PN�.��]0; $ umount /tmp/clear $ ls /tmp/clear /tmp/enc /tmp/clear: /tmp/enc: 8OHYnVwB4Hj4t, $