Extending libhijack to support filesystem image operations? about linux HOT 6 CLOSED

Closing this issue as the use-case described here can be solve using lklfuse and we have #201 to cover the more general case.

from linux.

Did you try lklfuse?

from linux.

@wrouesnel The trick is figuring out when you want open(2) calls to be forwarded to the host filesystem and when you want them to go inside LKL, since you only have a path (sometimes absolute, sometimes relative) to work with. I suspect hijacking all open calls would end up breaking a lot of programs out of the box, or make them behave unexpectedly (e.g. your logs would end up being written to the LKL filesystem rather than the host system).

from linux.

Well I'm specifically wanting to untar an FS backup into a filesystem image, but was looking to mostly preserve tar's syntax (i.e. not just rewrite tar).

But a little exploration does make it seem like it'd be easier to just do some find/replacing in tar's source tree rather then reverse engineering it's syscall's just now - you definitely run into trouble when you need to distinguish interesting host device paths from filesystem paths.

from linux.

I've been working on musl libc support for arch lkl in my local repo. Though it's still not done yet but let you know once it gets the shape.

With that I believe it makes sense a lot.

from linux.

@wrouesnel I believe it is easier to just create a wrapper script on top on lklfuse:

lklfuse fsimage /mnt/dir
tar xf file.tar /mnt/dir
fuseumount -f /mnt/dir

from linux.