On Tue, Aug 18, 2009 at 11:57:13AM +0100, Matthew Booth wrote:

I hit the following weirdness in guestfish:

...

<fs> ll /../proc/modules -r--r--r-- 1 root root 0 Aug 18 10:37 /sysroot/../proc/modules

...

<fs> cat /../proc/modules libguestfs: error: open: /../proc/modules: No such file or directory

The underlying reason for this seems to be that ll uses sysroot_path to establish a path before operating on it, whereas cat uses CHROOT_IN and CHROOT_OUT to open() inside a chroot. It seems to me that wherever a path is used directly by a command, there should never be a reason to use chroot because the real path can always be worked out. The only place I see for using a chroot is in command and sh.

Is it worth making a bulk CHROOT_IN and CHROOT_OUT removal patch?

No, because it would be the wrong thing to do. First of all, the command "ll /../proc/modules" is undefined behaviour. You probably meant to use this command: debug ll /proc/modules http://git.et.redhat.com/?p=libguestfs.git;a=commitdiff;h=24a6cf4533118e0436... Of course, that won't work unless libguestfs was configured with debug enabled (./configure --enable-debug-command), and that is intentional. I can't see a reason why you'd want to see the list of kernel modules installed in the appliance, but if there is a reason, it should be exposed as a new command. On the wider issue, as many commands as possible should be changed to use chroot. However in cases where we have to run an external binary in the appliance (as in 'll' which runs /bin/ls) we cannot use chroot, because the binary isn't located in the chroot, so we have to prefix paths with sysroot and hope for the best. This is a compromise, and chroot would be more desirable if we were able to use it. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top